Bon, ben déjà, merci d'avoir confirmé le point 2. J'ai effectué quelques tests unitaires avec les tables définies ci-dessus, et ça correspond bien à mes besoins, et réagit comme prévu, notament lorsqu'un échec d'ajout est constaté, que ce soit dans une transaction ou non.
Pour ton point 1, par contre, j'avoue avoir réfléchi un peu à la question que tu soulèves, et j'avoue ne pas vraiment comprendre ou saisir tous les tenants et aboutissants de cette manière de procéder.
Postgres (mais il ne doit pas être le seul) me permet sans difficulté d'indexer mon champ primaire tel que défini ci-dessus, et permet aussi de faire ces petites choses tellement pratiques que sont les "on update cascade" et consorts.
Du coup, si la structure de ce champ doit changer, ça ne me complique pas plus la vie que ça. Bref, il doit y avoir quelque chose qui m'échappe.
Quant-au fait de cacher la clef primaire aux utilisateurs, là encore, je ne comprends pas bien le pourquoi du comment, car c'est un identifiant unique qui permet à coup sûr d'identifier un enregistrement particulier d'une table. Lorsque l'utilisateur fait une recherche sur cet identifiant, il est certain de n'avoir qu'un seul résultat, et donc les erreurs de traitement possible sont moindres. Si tu masques ce champ "automatique" pour en afficher d'autre(s) qui font le même travail, ta base de données comporte tout un tas de champs qui sont redondants, et j'avoue ne pas en comprendre l'intérêt.
M'enfin, je cherche juste à comprendre, pas à démolir ta façon de travailler.
Merci de m'avoir confirmé le point 2, car je vais maintenant pouvoir avancer.
[^] # Re: .
Posté par Gyro Gearllose . En réponse au message Créer une clef avec une fonction. Évalué à 2.
Pour ton point 1, par contre, j'avoue avoir réfléchi un peu à la question que tu soulèves, et j'avoue ne pas vraiment comprendre ou saisir tous les tenants et aboutissants de cette manière de procéder.
Postgres (mais il ne doit pas être le seul) me permet sans difficulté d'indexer mon champ primaire tel que défini ci-dessus, et permet aussi de faire ces petites choses tellement pratiques que sont les "on update cascade" et consorts.
Du coup, si la structure de ce champ doit changer, ça ne me complique pas plus la vie que ça. Bref, il doit y avoir quelque chose qui m'échappe.
Quant-au fait de cacher la clef primaire aux utilisateurs, là encore, je ne comprends pas bien le pourquoi du comment, car c'est un identifiant unique qui permet à coup sûr d'identifier un enregistrement particulier d'une table. Lorsque l'utilisateur fait une recherche sur cet identifiant, il est certain de n'avoir qu'un seul résultat, et donc les erreurs de traitement possible sont moindres. Si tu masques ce champ "automatique" pour en afficher d'autre(s) qui font le même travail, ta base de données comporte tout un tas de champs qui sont redondants, et j'avoue ne pas en comprendre l'intérêt.
M'enfin, je cherche juste à comprendre, pas à démolir ta façon de travailler.
Merci de m'avoir confirmé le point 2, car je vais maintenant pouvoir avancer.