Par "à la main" je voulais dire "en rajoutant du code applicatif pour le vérifier avant de l'insérer." Ce qu'on doit trouver dans le code, c'est ce qu'on fait quand le SGBD nous répond "euh tu fais n'importe quoi mon coco, ta donnée, je ne te l'insère pas". Peut-être qu'entre le moment où tu as commencé à créer ton tuple et celui ou tu le finis, quelqu'un d'autre a supprimé ta clé primaire. Tu peux évidement faire du code qui redemande à la base de donnée si elle existe toujours, mais ça fait, dans la plupart des cas, du code exécuté en plus.
Par exemple si tu veux commander un billet de train et que le train est supprimé entre le moment où tu as demandé la liste des trains et celui où tu as finalement choisi que tu voulais un siège côté couloir dans celui de 13:37 (au bout de dix minutes), comme la suppression d'un train est un évènement rare, revérifier que le train 42 existe toujours au début de ta transaction est inutile, vu que la base de donnée va de toute façon le faire pour toi. Et tu gères le cas ("la SNCF s'excuse mais finalement il n'y a pas de train") au moment où la base de donnée te le dit.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Mauvaise méthode de développement ?
Posté par 2PetitsVerres (Mastodon) . En réponse au journal MySQL est une bouse immonde. Évalué à 4.
Par "à la main" je voulais dire "en rajoutant du code applicatif pour le vérifier avant de l'insérer." Ce qu'on doit trouver dans le code, c'est ce qu'on fait quand le SGBD nous répond "euh tu fais n'importe quoi mon coco, ta donnée, je ne te l'insère pas". Peut-être qu'entre le moment où tu as commencé à créer ton tuple et celui ou tu le finis, quelqu'un d'autre a supprimé ta clé primaire. Tu peux évidement faire du code qui redemande à la base de donnée si elle existe toujours, mais ça fait, dans la plupart des cas, du code exécuté en plus.
Par exemple si tu veux commander un billet de train et que le train est supprimé entre le moment où tu as demandé la liste des trains et celui où tu as finalement choisi que tu voulais un siège côté couloir dans celui de 13:37 (au bout de dix minutes), comme la suppression d'un train est un évènement rare, revérifier que le train 42 existe toujours au début de ta transaction est inutile, vu que la base de donnée va de toute façon le faire pour toi. Et tu gères le cas ("la SNCF s'excuse mais finalement il n'y a pas de train") au moment où la base de donnée te le dit.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.