Version imprimable
Bonjour,
En réponse à un topic dans la section plus générale "Décision SGBD", je viens de rédiger un petit article présentant une méthodologie afin de transformer une base mal modélisée en une base correctement modélisée, sans pour autant devoir réécrire tous les programmes annexes.
Vu que mes exemples ont été écrits avec SQL Server, je le poste ici :
http://www.developpez.net/forums/blo...-base-donnees/
J'espère que vous le trouverez utile :)
Intéressant
Par contre je ne partage pas ce point de vue : "Et la présence de NULL dans une table, c'est la preuve d'une modélisation hasardeuse"
Null a un sens particulier, dont la seule alternative est parfois un varchar de longueur zéro, ce qui n'est pas mieux
Par exemple, je suis intervenu il y a pas mal d'années dans un projet de migration vers la norme EMV appliquée aux informations des mouvements cartes bancaires.
il y a dans cette norme un très grand nombre d'attributs dont toutes les valeurs de X'00' à X'FF' ont un sens fonctionnel, la seule façon d'exprimer l'absence d'information est la valeur "NULL" (ou l'alternative varchar de longueur zéro qui présente encore plus d'inconvénients)
En fait une colonne NULLable est parfaitement justifiée si l'information existe TOUJOURS, mais qu'elle n'est pas connue à l'instant t.
L'exemple typique du NULL justifiable est la date de fin d'un intervalle pour un événement. Lorsque l'on insère une ligne, à l'évidence, la date de début doit être connue, mais la date de fin, c'est très improbable !
A +
Oui, en partant de mon exemple, le NULL est idiot (tout comme une chaîne vide, un espace, ou 10 zéros) du moment que sa signification est "j'ai pas l'information", et "je l'aurai certainement jamais".
Dans ce cas, à l'image des numéros de téléphone, si on commence par stocker des colonnes nullables pour chaque type de numéro de téléphone, on va se retrouver avec 10 ou 20 colonnes, car y'a toujours un blaireau qui va avoir 3 téléphones pros différents, dont certains sont des mobiles, d'autres des fax ou des fixes, et qu'on sera obligé de gérer tous les cas... Alors que dans 99.9% des cas, seules 1 à 2 colonnes seront remplies, et pas toujours les mêmes !
A ce moment, les NULL sont une erreur de modélisation.
En revanche, dans une application servant à gérer des dossiers médicaux par exemple, si on n'a pas toujours la date de naissance au moment de la prise de contact initiale avec le patient, il est parfaitement acceptable de la gérer comme nullable, car on est certains que cette information sera connue au moment où on va récupérer le dossier médical du client auprès de la SECU.
Car le fait de pas avoir l'information à un sens "il faut la demander", et on sait qu'on l'aura forcément un jour.
En revanche, ton numéro de téléphone satellite professionnel 4, je suis pas certain que tu en es un jour, donc de là à me le donner pour remplir ma colonne de NULL... ;)