[R] SQLite_Exec UPDATE et DELETE

Aide et conseils concernant AutoIt et ses outils.
Règles du forum
.
Avatar du membre
jchd
AutoIt MVPs (MVP)
AutoIt MVPs (MVP)
Messages : 2284
Enregistré le : lun. 30 mars 2009 22:57
Localisation : Sud-Ouest de la France (43.622788,-1.260864)
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#21

Message par jchd »

Par exemple : que se passe-t-il dans le cas d'une concaténation de plusieurs fichiers dont les enregistrements portent des numéros identiques ?
On omet simplement l'ID dans la liste des colonnes lors de l'insert dans tous les cas. Dans un schéma typique l'ID possède l'attribut autoincrement donc SQLite attribue un numéro libre dans tous les cas, sans aucun risque.
Le champ "type" contient le type de registre dépouillé.
Je verrais d'un bon oeil la traçabilité de la base vers les sources, sous forme d'une référence précise vers le registre et l'endroit d'où provient l'information (type de document, lieu, numéro de registre, numéro de page, de ligne ou autre).

On peut faire automatiquement un certin nombre de vérifications de cohérence, par exemple ajouter au schéma :

Code : Tout sélectionner

CREATE TRIGGER [trInsChkPèreM]
BEFORE INSERT
ON [Liste]
FOR EACH ROW
WHEN (select sexe from Liste where Id = new.PèreId) != 'M'
BEGIN
     select raise(abort, 'Le père n''est pas un homme.');
END;

CREATE TRIGGER [trInsChkMèreF]
BEFORE INSERT
ON [Liste]
FOR EACH ROW
WHEN (select sexe from Liste where Id = new.mèreId) != 'F'
BEGIN
     select raise(abort, 'La mère n''est pas une femme.');
END;
CREATE TRIGGER [trUpdPèreId]
BEFORE UPDATE OF [PèreId]
ON [Liste]
FOR EACH ROW
WHEN (select sexe from Liste where Id = new.PèreId) != 'M'
BEGIN
     select raise(abort, 'Le père n''est pas un homme.');
END;

CREATE TRIGGER [trUpdMèreId]
BEFORE UPDATE OF [MèreId]
ON [Liste]
FOR EACH ROW
WHEN (select sexe from Liste where Id = new.mèreId) != 'F'
BEGIN
     select raise(abort, 'La mère n''est pas une femme.');
END;
 
SQLite s'assurera que le père renseigné est un homme et la mère une femme, aussi bien lors d'un insert que de l'update de l'une ou l'autre ID parent. A défaut, une erreur sera renvoyée et la base restera dans un état cohérent.
Ce type de vérification est facile à mettre en oeuvre et ne coûte que la fatigue des phalanges pour l'implémenter une fois, quelque soit le nombre d'applications distinctes qui utilisent cette base. Dans le cas présent on n'a aucun besoin de se poser la question de l'optimisation de la vitesse d'insertion ou d'update, donc on peut multiplier ces contraintes de cohérence au niveau de la base elle-même.

Par contre je n'ai pas (encore) imaginé de contraintes fortes au niveau des dates, car les informations chronologiques pré- état-civil me semblent bien souvent aléatoires ou insuffisament précises pour être utilisables systématiquement. Je me gourre peut-être.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
aulus
Niveau 7
Niveau 7
Messages : 424
Enregistré le : lun. 25 mars 2013 19:38
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#22

Message par aulus »

Je verrais d'un bon oeil la traçabilité de la base vers les sources, sous forme d'une référence précise vers le registre et l'endroit d'où provient l'information (type de document, lieu, numéro de registre, numéro de page, de ligne ou autre).
Ces champs sont, bien sûr, prévus.
SQLite s'assurera que le père renseigné est un homme et la mère une femme, aussi bien lors d'un insert que de l'update de l'une ou l'autre ID parent.
Le sexe est demandé à l'utilisateur lorsqu'il n'est pas prévisible (cas des témoins, des défunts, des nouveau-nés par exemple), et il est donné automatiquement par le programme lorsqu'il est naturellement défini (cas des pères et mères, époux, épouse).
Par contre je n'ai pas (encore) imaginé de contraintes fortes au niveau des dates, car les informations chronologiques pré- état-civil me semblent bien souvent aléatoires ou insuffisament précises pour être utilisables systématiquement. Je me gourre peut-être.
Le programme doit gérer, entre autres, les problèmes de calendrier (grégorien/républicain).

Construire un programme de dépouillement est une tâche immense. Heureusement qu'on ne le sait pas au début, sinon on ne se lancerait jamais dans une telle aventure ! Quand j'ai réglé un problème, un autre surgit ! Mais j'ai dépassé le point de non-retour...
Avatar du membre
jchd
AutoIt MVPs (MVP)
AutoIt MVPs (MVP)
Messages : 2284
Enregistré le : lun. 30 mars 2009 22:57
Localisation : Sud-Ouest de la France (43.622788,-1.260864)
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#23

Message par jchd »

C'est bien tout ça mais il faudrait un jour formaliser ton besoin de manière plus concrète parce que là tu deviens une cible mouvante ou à tout le moins trop floue pour stabiliser l'image.
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Avatar du membre
mikell
Spammer !
Spammer !
Messages : 6292
Enregistré le : dim. 29 mai 2011 17:32
Localisation : Deep Cévennes
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#24

Message par mikell »

aulus a écrit :Le programme doit gérer, entre autres, les problèmes de calendrier (grégorien/républicain).
Alors peut-être que ça t'intéressera
► Afficher le texte
Sinon j'imagine que plus on remonte dans le temps, plus les données correspondent à de fortes présomptions plutôt qu'à des certitudes, et il devient alors risqué de vouloir trop automatiser la manipulation de ces données ...
" L'échec est le fondement de la réussite. " (Lao-Tseu )
" Plus ça rate, plus on a de chances que ça marche " (les Shadoks )
aulus
Niveau 7
Niveau 7
Messages : 424
Enregistré le : lun. 25 mars 2013 19:38
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#25

Message par aulus »

jchd a écrit :C'est bien tout ça mais il faudrait un jour formaliser ton besoin de manière plus concrète parce que là tu deviens une cible mouvante ou à tout le moins trop floue pour stabiliser l'image.
Maîtrisant bien mal autoit et SQLite, j'ai dû donner l'impression que je pilotais à vue. Mais il n'en est rien. Je sais ce que je veux obtenir. Nous l'avons défini en association. Encore quelques jours de programmation et voguent les tests...
mickell a écrit :Sinon j'imagine que plus on remonte dans le temps, plus les données correspondent à de fortes présomptions plutôt qu'à des certitudes, et il devient alors risqué de vouloir trop automatiser la manipulation de ces données ...
J'ai testé le code de conversion des dates : il est au top. J'admire votre rapidité de codage...
Non, pas de présomptions sur les données. Nous ne faisons que les lire et les enregistrer dans des bases pour plus facilement les exploiter. On ne se pose pas de questions existentielles. On relève ce qu'on lit, point. Mais d'accord sur votre avis concernant l'automatisation trop poussée dans la manipulation des données.
Avatar du membre
mikell
Spammer !
Spammer !
Messages : 6292
Enregistré le : dim. 29 mai 2011 17:32
Localisation : Deep Cévennes
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#26

Message par mikell »

aulus a écrit :Je sais ce que je veux obtenir. Nous l'avons défini en association.
Dans ce cas, un bon cahier des charges très précis et clairement établi permettrait de rationnaliser et d'économiser énormément de temps et de sueur pour définir le codage strictement nécessaire pour les fonctionnalités souhaitées
Sinon c'est jchd et moi qui à force d'hypothèses naviguons à vue :mrgreen:
" L'échec est le fondement de la réussite. " (Lao-Tseu )
" Plus ça rate, plus on a de chances que ça marche " (les Shadoks )
aulus
Niveau 7
Niveau 7
Messages : 424
Enregistré le : lun. 25 mars 2013 19:38
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#27

Message par aulus »

mikell a écrit :Dans ce cas, un bon cahier des charges très précis et clairement établi permettrait de rationnaliser et d'économiser énormément de temps et de sueur pour définir le codage strictement nécessaire pour les fonctionnalités souhaitées
Sinon c'est jchd et moi qui à force d'hypothèses naviguons à vue :mrgreen:
Mes demandes d'aide sur ce forum se limitent à l'utilisation des fonctions d'autoit puis de SQLite qui sont loin d'être évidentes, et parfois bien surprenantes. Par exemple : afficher les scrollbars des fenêtres et les rendre fonctionnelles, c'est le parcours du combattant... une après-midi d'âpre lutte !... C'est des recherches interminables sur internet... Certaines aboutissent. D'autres conduisent à des cas très particuliers. D'autres enfin aboutissent à des réponses rédigées par des gens pas plus dégourdis que moi. (J'ai trouvé un site qui affirmait qu'AutoIt ne permettait pas d'écrire des programmes, mais se limitait à coder quelques macros !) . Le secours venait alors de ce forum et j'ai été bien heureux de trouver des personnes comme vous, calées dans ces langages pour me remettre sur la bonne voie, signaler mes erreurs de code, me conseiller. Je vous en suis très reconnaissant. Et j'espère que vous n'avez pas trop sué à plancher sur les fonctionnalités de mon programme, car telle n'était pas mon intention en intervenant sur ce forum. Ce message me donne encore l'occasion de vous remercier et... de m'excuser si je vous ai amenés à penser que j'attendais de vous que vous étudiiez pour moi les fonctionnalités à insérer dans un programme de dépouillement de données généalogiques.
Avatar du membre
mikell
Spammer !
Spammer !
Messages : 6292
Enregistré le : dim. 29 mai 2011 17:32
Localisation : Deep Cévennes
Status : Hors ligne

Re: [R] SQLite_Exec UPDATE et DELETE

#28

Message par mikell »

Non non pas de souci...
Quand on aide quelqu'un sur un script, il arrive que le fond de la question nous interpelle et on va donc s'y investir davantage, voire se laisser prendre par l'enthousiasme
Pour jchd qui est un fondu de SQL, le motif est évident (mais je ne m'avancerai pas plus)
Dans mon cas, je fournis rarement des codes complets aussi compliqués sauf quand faire ces codes me permet aussi d'apprendre moi-même des choses et de m'éclater, et là transpirer n'est évidemment plus un problème
Mais les réponses qu'on apporte peuvent ne pas forcément correspondre à tes attentes, d'où mon message précédent

Cela dit si ouvrir un sujet sur le forum te permet de t'épargner une galère, tu aurais bien tort de ne pas en profiter :mrgreen:
" L'échec est le fondement de la réussite. " (Lao-Tseu )
" Plus ça rate, plus on a de chances que ça marche " (les Shadoks )
Répondre