Un SGBD-R permet de gérer les relations entre les éléments, et de les "enforce", c'est à dire d'en assurer l'intégrité.
 
Ainsi, on note deux systèmes de verroux de base et un personnalisable.
 
Les verroux de base.
Il s'agit des clés primaires et étrangères.
Pour ce qui est de la clé primaire, lorsqu'un champ (ou un tuple de champs) est spécifié comme clé primaire, alors le moteur de la base de données va interdire que ce tuple prennent plusieurs fois la même valeur.
Et niveau clé étrangère, cette fois le SGBD va s'assurer avant l'insertion de valeur dans ce tuple, que ces valeurs existent déjà dans la table de référence.
 
Ces deux systèmes de base permettent de s'assurer par exemple que deux clients n'auront pas le même numéro de client, ou qu'on ne pourra pas associer un produit qui n'existe pas à une commande.
 
Les verroux personnalisables.
Il s'agit des triggers. Plus que des verroux, un trigger permet de faire à peut près n'importe quelle action sur une action spécifique, sur un objet spécifique. Ainsi, on pourra par exemple se servir d'un trigger pour mettre à jour le prix total d'une commande lorsque la quantité d'un produit change. Etant des calculs évolués, cela permet au SGBD de se comporter exactement comme vous l'entendez.
 
Ces méthodes permettent de mettre en application les méthodes d'analyse tels que Merise, et d'assurer, au sein du stockage des données, l'intégralité et la cohérence de ces dernières.
 
 
Sur le papier, tout ça c'est très bien... Mais... Oui, il y a un mais...
 
Regardons ce qu'il se passe sur une clé primaire.
-> Lorsqu'on ajoute une valeur, le SGBD va en premier rechercher la présence de cette valeur dans la table, puis l'insérer si elle n'existe pas. PUIS, étant donné qu'une clé primaire est systématiquement associée à un index unique, elle va vérifier l'existance de cet élément dans l'index unique, et l'ajouter si elle n'existe pas (ce qui est forcément le cas si on est allé jusque là).
 
Ca fait pas mal de trucs... Voyons voir ce que ça donne si on supprime cette contrainte, et qu'on ne garde que l'index unique.
-> Recherche de la valeur dans l'index. Si elle n'existe pas, insertion de la donnée, mise à jour de l'index, sinon, erreur.
On a fait 2 traîtements de moins.
 
=> Il ne faut pas utiliser de clé primaire sur une table. Un index unique suffit, et offre le même résultat en un temps plus rapide.
Deplus, les clé alternatives n'existant que rarement dans les SGBD, elles sont habituellement traîtées de cette façon, alors qu'il n'y a pas de raison de les différencier.
 
Maintenant, penchons-nous sur la clé étrangère.
-> Lorsque j'insère une donnée dans la table "fille", je regarde si la donnée liée existe dans la table mère. Si elle existe, j'insère ma ligne, et si elle n'existe pas, je fait une erreur. Ceci peut prendre pas mal de temps si la table mère contient beaucoup de données, ou que le tuple servant de lien est gros.
Lorsque je supprime une donnée de la table "mère", je regarde si des données de la table fille y font référence. Si oui, alors je plante, sinon je supprime la ligne. Ceci est encore plus lent, puisque très généralement il y a plus de filles que de mères. Sans compter le fait que du côté mère, ce champ est forcément unique, tandis que côté fille, il ne l'est pas.
 
Quand j'ai un programme qui me permet de remplir un formulaire ou les données de la table mère sont listées dans une dropdown list, quel est l'intérêt d'aller vérifier qu'elle existent dans la table mère au moment de l'insertion ? Aucun, puisque ces données existes forcément !
Et dans un traîtement de suppression d'une donnée de référence, pour éviter de planter si des données existent dans la table fille, on va de toute façon nettoyer cette dernière en premier. Ainsi, au moment du delete sur la table mère, on est certains qu'il ne peut pas y avoir de filles, vu qu'on vient de toutes les effacer. A nouveau, aucun intérêt.
 
=> Les clé étrangères ne servent donc à rien, et c'est au programme de s'assurer de l'intégrité des données lors de ces accès à la base. Il vaut donc mieu éviter de les utiliser, afin d'économiser les traîtements inutiles.
 
A noter deplus le problème du CASCADE CONSTRAINTS. Cette fabuleuse commande permet de supprimer une mère et toutes ses filles en une ligne.
Elle a aussi la formidable capacité à vider la moitiée des tables de la base en une seconde si on écrit mal la requête... Dans ce cas, le segment de rollback étant sous-dimensionné, ça plante, et on ne peut plus faire rollback. La catastrophe. Sans clé étrangère, aucun risque, le CASCADE CONSTRAINTS ne retrouvant pas de cheminement entre les table, ne pourra faire aucun dégat.
 
-> Les triggers. Un trigger s'éxécute sur différents évèments et différentes actions sur différents objets. Un trigger est généralement utilisé sur une table (mais ça peut aussi bien être sur une vue pour les SGBD récents), avant ou après la modification de la table, sur une insertion, une suppression ou/et une mise à jour.
L'éxécution du trigger sera systématique lorsqu'un tel traîtement aura lieu sur son l'objet qu'il surveille. Ainsi, si un trigger s'occupe de mettre à jour le montant d'une commande en fonction des produits qui y sont rattachés, la moindre modification d'un libellé d'un produit dans la liste va déclencher le calcul, même si aucune quantité ni prix n'a été modifié.
 
-> Un trigger fonctionne dans sa propre sous-transaction
-> Un trigger peut tout à fait déclencher d'autres triggers
-> A savoir qu'une sous-transaction fonctionne comme de la récusrivité : c'est la transaction principale qui encaisse tout. On voit rapidement que pour certains trigger un rollback segment fault risque d'arriver, avec toutes les erreurs et incohérences que cela peut engendrer.
-> Un trigger, étant écrit à la main, ne peut pas bénéficier des optimisation des PK et FK (qui sont en réalité des triggers automatiques), et se contenteront d'utiliser du code SQL et dérivés (PL/SQL ou T-SQL pour ne citer qu'eux), ce qui risque rapidement de prendre du temps.
 
=> La plus part des traîtements par trigger peuvent être évités en faisant attention à ce qu'on fait au niveau du programme qui utilise la base de données. Le calcul d'un total d'une commande notamment, n'a rien à faire dans la base, il a sa place dans le programme, d'autant plus que c'est plus évident de modifier un programme pour y rajouter des frais de port ou la TVA que dans un trigger...
 
En bref, les triggers sont à éviter autant que possible. Les seuls qui sont vraiment acceptables, sont ceux qui vont s'occuper de générer un identifiant (pour les bases qui n'ont pas de fonction native).
 
On crééra alors un trigger "on before insert" qui s'occupera d'aller récupérer la valeur d'une séquence par exemple. Sorti de ça, les tests comme exclusion de champs, surtout lorsque le trigger se lève sur un traîtement fréquent, et lorsque ses traîtements sont longs, doivent impérativement déportés dans l'application.
 
 
Voilà. C'était juste parceque j'avais rien à faire et que j'ai pas de question à poser, et y'a pas de réponse auxquelles répondre, donc j'étalle ma science, ça peu toujours servir si un jour une personne se pose la question

Bon, Magic, je termine mes heures de boulot et puis je m'occupe de toi puisque, ENCORE UNE FOIS, tu racontes n'importe quoi.

pour le fight Gizmo/MagicBuzz

Ben tu pourra regarder là aussi
http://forum.hardware.fr/hardwaref [...] 3960-1.htm

 
   pour mettre à jour l'autre topic slon comme ca évolue
 
Au fait par rapport àce qui a été dit dans le premier post :
- je suis a peu pres d'accord sur les clé/index (si c faux j'aimerai bien comprendre pourquoi)
- je suis a peu pres d'accord sur les triggers mais c'est discutable, selon l'utilisation qu'on en fait
 
En revanche, en ce qui concerne l'utilisation des clé étrangères, je ne pense pas que ce soit une bonne solution de les dégager en pensant que tout sera pris en charge par un logiciel/truc d'interface derrière. Parce que si jamais il y a le moindre problème, et même si il y a peu de chance qu'il arrive, après tu dis au revoir à ta cohérence des données.
 
J'aimerai bien avoir l'avis d'autre personne.
 
EDIT : c'est mon message le edit  

Y'aura pas de fight, je bosse suffisament dans le monde de l'ERP pour savoir de quoi je parle.

Bon, j'ai fini mon boulot. A nous deux.
 
Désolé par avance pour ceuxx qui voudraient me quoter, mais il faudra jouer au copier/coller.
 

lol, je ne vais pas me faire chier à répondre à chacun de tes arguments. Ils ne reflètent qu'une chose : tu n'as jamais bossé sur un gros environnement, point barre.
 
La dénormalisation que tu mets en cause dans mon exemple de stockage des prix en est la preuve. Je ne met pas en doute le savoir faire que tu mets dans la création de triggers super compliqués de la mort qui tue la vie... Seulement ton mode de fonctionnement est totalement inadapté à une utilisation intensible de la base, et encore moins à une gestion réellement complexe des données.
 
Pour info, tous les points et argiments que j'ai cités sont tirés de l'analyse de 3 ERP, dont les deux plus gros...
 
Generix, sur lequel je travaille tous les jours, qui est un petit ERP à la puissance exceptionnelle (il dépasse les deux autres sur ce plan malgré certaines lacunes), puis les deux mastodontes que sont SAP et Oracle Application.
 
C'est marrant quand même... Mais chacun de ces 3 ERP, dont SAP et Oracle Application n'ont pas à faire leurs preuves quant à leur stabilité et leur puissance, condament systématiquement les points que tu avance avec ferveur...
 
Alors évidement, appliquer de la TVA à un prix c'est simple, mais fait un jour de l'informatique de gestion dans une multi-nationnale, et tu verras que ça ne se limite pas à faire une multiplication de deux nombres, pas plus que calculer le prix d'une ligne de commande en fonction de la quantité commandée.
 
Des exemples mettant en évidence l'intérêt de dénormaliser une base, et de se priver des verrous du SGBD, on en trouve à la pelle, ça m'en fait chier de t'en donner tellement il y en a.
 
M'enfin bon, si tu ose dire que les gars qui ont développé Oracle Application sont des gros nazes qui ne savent pas :
- Utiliser une base de données (c'est quand même eux les éditeurs du SGBD le plus puissant du marché)
- Faire un soft qui garanti l'intégrité des données qu'il gère
- Faire un soft capable de récuperer un état stable des données après une panne matérielle
 
Ben laisse moi mourrir de rire.
 
Pour info, récement, le serveur de Generix qui est utilisé dans la filliale de GE chez qui je travaille actuellement a eu un leger problème matériel... Y'a juste un des 4 processeurs qui a grillé.
Unix a immédiatement réagit en passant en runlevel 3, ce qui a eu pour effet un superbe terminte sur tous les process actifs.
Une heure après, Generix était à nouveau opérationnel, avec en tout et pour tout les 5 dernières minutes d'activité de perdues... Et pourtant Generix est très certainement le moins fiable des 3 ERP que j'ai cité.
 
Essaie de faire mieu avec des PK et FK à plus savoir qu'en faire.
 
Et sinon, pour info, je ne sais pas sur quelle base tu travailles, moi c'est Oracle 8.x et 9.x, et à l'occasion SQL Server 7.0 ou 2000. Aucun des deux ne permet de créer un index unique contenant des valeurs nulles... Et chacun des deux gère les PK en doublon des index uniques... Il suffit de regarder comment ça se passe quand tu inserre une valeur unique dans une FK et dans un index unique pour le voir... La FK raise une erreur avant que le SGBD ait tenté de créer la ligne, alors que l'index raise l'erreur au moment de l'insertion dans l'index, preuve que la FK effectue un contrôle de vérification en amont, qui offre un surco$ut de tra$itement non négligeable.

Ouais non, c'est clair, des utilisateurs qui t'extirpent 80% de la DB en une fois, qui lancent des job qui bouffent plus d'1Go de ram (active, sans le swap) chacun, qui te font des modifications de structure de la DB au vol, non, je n'ai jamais bossé sur un gros environnement qui demande une grosse charge, c'est clair
 
Et puis, si tu prends, ente autre, SAP comme exemple à suivre, je "comprend" tes dires...
 
Pour ce qui est du calcul du prix, qu'il soit interne ou externe à la DB, je ne vois pas ce que cela change au niveau de l'algorythme. Par contre, je vois bien que tu as une mauvaise modélisation (et une approche bizare du client si son prix à payer dépend du moment où il règles la facture).
 
Pour ce qui est de oracle application, je ne l'ai pas testé, mais dire que le fait qu'il aie développé le SGDB le plus puissant (en terme de quoi?) implique une bonne cohésion est unehérésie. Sinon windows serait le meilleurs OS (en terme de rapidité, stabilité, sécurité) et les produits dérivés ne devraient pas souffrir de la version de celui-ci ni de son état. On sait clairement que ce n'est pas le cas. (Tu vois, moi aussi je sais faire semblant d'avancer des arguments tout en brassant du vide)
 
Pour l'exemple du crash test, J'ai essayé avec sur mon système. D'une part avec un kill -9 sur le serveur, d'autre part en débranchant la prise. Mis à part les transactions en cours (ce qui est normal et SUR), rien n'était perdu. Et pas besoin d'utiliser un système de backup ou de synchronisation temps réel comme le font certains ERP.
 
Sinon, pour ton info:
Unique Key     Column(s) value(s) must be unique in table or null (see note below)
Tiré de la doc de Oracle 8i (et 9i) (mais bon, t'es un cador, t'as surement du là jouer au bluff)
Et ton exemple sur la FK est stupide et n'a aucun rapport avec la PK.
 
Sur ce, à moins que tu aies des contres-exemples chiffrés, avec calcul de risque et mécanismes supplémentaires mise en oeuvre pour garantir l'intégrité des données, je considère la discussion close. Pour moi, une firme qui possède un SGDB mais qui ne le pense pas suffisament rapide et fiable pour implémenter en externe ce qu'il sait faire nativement a déjà un énorme problème à régler.
 
EDIT: un dernier détail: Dans un ERP, les gens (utilsateurs) n'ont, la plupart du temps, pas le loisir d'interroger la DB dans tous les sens, ils sont confiné dans ce que les programmeurs ont prévu pour eux. Ils ont donc nettement moins de chance de tomber sur des données orphelines après un crash ou autre. Dans un système comme le mien, ils ont deux possibilités: accès directe en SQL à la DB et donc à toutes les requètes de sélection (et dans certains cas d'écriture) àla DB ou création de requètes dans un méta-langage quiinterroge la DB selon le modèle conceptuel GER. Dans uaucun des cas, je ne peux me permettre d'avoir des données fausse que j'éliminerais en background.

Pour info, je bosse sur des gros systèmes de facturation (Rating / Billing) pour les opérateurs de télécoms.
 
On a 2 principaux systèmes dans notre boîte, les 2 sous Oracle.
 
Le premier fait une utilisation intensive de foreign keys / triggers, et est extrêmement 'scalable'. Les accès à la base se font par une logique d'APIs XML assez complexe mais qui tient la charge. Il est utilisé par les plus gros opérateurs télécoms américains.
 
Le deuxième est fait pour des opérateurs plus petits, mais à la recherche d'offres téléphoniques plus complexes. Aucune FK, presque aucun trigger dans la BDD, toutes les contraintes de cohérence sont gérées par le code (des APIs sous formes de proc. stoquées PL/SQL), mais ça tourne quand même très bien, en tout cas la partie Rating est très 'scalable'. Il est utilisé par un grand nombre d'opérateurs européens.
 
Les 2 systèmes utilisent bien sûr des primary keys partout Et comme vous pouvez vous en doutez, les logiques de transactions, la complexité des calculs, etC. sont des points importants de tel systèmes ...

 
Tout à fait
Dans le cas du premier système que j'ai cité au-dessus, les accès en base se font en lecture et en écriture par des APIs, qui garantissent l'intégrité des données et permettent de se détacher complètement du modèle de données.
 
Dans le cas du second système, les accès en base se font :
- en lecture, par des vues, pour toute sorte d'info à récupérer,
- en écriture, par des APIs, qui garantissent l'intégrité des données.

d'où j'en déduis que les deux ont raisons, et qu'ils s'écharpent pour rien

Plusieurs points.
 
1) Ce que j'appelle un gros environnement, c'est pas faire une requête qui bouffe 1 Go de RAM et récupère 80% des données de la base en faisant des calculs à la mort moi le noeud. Un gros environnement, c'est quand t'as 2000 utilisateurs en train d'accéder à la base en même tems, avec les x transactions concommitentes que ca engendre. C'est dans ces situations qu'on peut pousser un SGBD dans ces limites d'un SGBD. Avec ton utilisation, c'est pas les mécanismes du SGBD que tu stresse, mais simplement les capacité matérielles du serveur : le serveur est saturé pendant tes requêtes, et seul l'upgrade matériel permet de noter une véritable différence. Ce n'est pas le cas d'un ERP ou un temps de réponse de plus de 5 secondes est inaceptable (ben oui, les besoins ne sont pas les mêmes). Dans ton environement précis, en effet, les FK notamment peuvent être avantageuses, car elles guident l'optimiseur du SGBD pour choisir les jointures et les index à suivre. Cependant, les FK générant des locks sur la FK justement lors des mises à jours, en cas d'accès concurrent intensif, tes perfs vont s'effondrer. (On ne peux pas lire dans une FK alors qu'on est en trai d'écrire dedans depuis une autre session, et ce, durant toute la transaction).
 
2) Oracle offre un grand nombre de paramètrages, notamment celui d'interdir des valeurs nulles dans un index unique. Personnelement, je n'ai jamais vu d'implémentation d'Oracle en acceptant. Après si en tant que DBA tu n'es pas foutu d'activer cette fonction, j'y peut rien. En tout cas, je ne vois pas l'intérêt de bosser avec un index unique qui contient des doublons.
 
3) Ensuite, tu laisse l'accès direct aux données de la base. Là encore cela reflète un besoin spécifique (que je trouve absolument anormal mais c'est une autre histoire). Evidement, si le premier utilisateur venu peut créer des données à la main, tu n'as pas d'autre choix que d'en assurer l'intégrité... Il est très rare cependant de donner un accès direct à la base, et heureusement. Généralement on se paie au moins le luxe d'écrire des proc stock et API permettant de le faire sans avoir à écrire les requêtes directement. C'est à ces objets de vérifier l'intégrité des données, les clés ne pouvant en aucun cas supporter des règles de gestion complexes de toute façon. Une FK ne t'empêchera pas de faire payer la TVA espagnole à un portugais exemplaté de TVA... Une proc stockée ou une API, si.
 
4) Ensuite, tu oses me dire que c'est pas normal qu'un client ne paie pas le même prix pour la même commande à deux moments différents ? Tu sors d'où ? Va simplement dans n'importe quel magasin, achète des produits, et le mois d'après achète les mêmes produits... Tu seras bien chanceux si les prix sont toujours les mêmes ! Et pourtant tu restera dans un modèle particulièrement simple :
- Pas de contrat de prix
- Pas de fluctuation dûe à la fluctuation des monnaies
- Pas de fluctuation dûe à un changement du prix d'achat
- Pas de fluctuation dûe à l'inflation des monnaies
Ce seraît la meilleure, si un client qui commande un produit en $ ne paie pas un prix différent quand le $ prends 2% sur l'€ dans le mois...
Si tu te sens d'attaque pour faire ensuite les fonctions financières qui recalculent le prix des commandes en fonction de ces paramètres qui varient avec le temps, je tire mon chapeau. N'oublie pas non plus que le comptable n'a pas la journée devant lui quand un inspecteur des impôts lui demande des comptes, et que c'est généralement un historique sur 4 ou 5 ans dont il a besoin... Avec quelques milliers de commandes par jour, ca va être chaud) faire !
 
Bref, des systèmes qui sont dans le cas que tu utilises, il y en a peut-être 200 en France, mais la principale utilisation d'un SGBD, c'est de l'informatique de gestion, qui correspond point par point à l'utilisation que j'en fais. Je pense que t'es quand même pas assez mauvais pour ne pas savoir qu'une opimisation dépend des besoins. Moi dans mes conseils, je parle du cas le plus répendu, toi d'un cas qui doit toucher 200 implémentation dans la France.
 
Note: A savoir qu'un site web a rigoureusement les mêmes besoins qu'un ERP : temps de réponse inacptable au bout de quelques secondes, nécessité de faire abstraction un maximum des transactions (sur un site web c'est carrément une limitation technique) et interdiction aux utilisateurs d'accéder directement dans la base.
 
A savoir pour ton exemple du POST généré a la mano par l'utilisateur, c'est très bien. Avec un FK sur la table de référence tu vas empêcher d'insérer la donnée orpheline.
 
Seulement, j'en connais pas beaucoup des exemples où tu inserre une donnée sans faire le moindre traîtement...
 
-> Je passe une commande sur un produit X ? Premier truc que je fais, c'est aller chercher son prix, et mettre à jour les stocks... Si ce produit n'existe pas, j'ai pas besoin d'aller chercher dans la table de référence pour m'en appercevoir, et en plus cela ne me garantira pas que le produit a un stock associé ni un prix, donc dans tout les cas la FK est rigoureusement inutile.

C'est ce que j'essaie de dire dans mon dernier post : les besoin de gizmo sont spécifiques, et dans son cas précis les méchanismes au niveau du SGBD ont en effet une réelle utilité. Cependant c'est loin d'être la cas général.

j'ai l'impression qu'entre Arjuna & Gizmo, l'un est pour les perf pure et l'autre pour la cohérence des données...associez vous !
perso j'opte plus pour la cohérence que pr les perf : perdre des données coute plus cher qu'upgrader un serveur
 

Le problème de l'upgrade du serveur, c'est que lorsque tu es en environnement stressé (grosse charge pour ce qui est du nombre de transactions concommitantes), ça ne change presque rien (enfin... c'est moi spectaculaire que lorsque tu demandes de gros traîtements en faible nombre a un serveur).
 
Deplus, j'insiste sur le fait que les FK ne garantissent pas l'intégrité des données, ou alors demandent, quand c'est possible une normalisation de la base qui va multiplier les traîtements et la quantité de données stockées.
 
Exemple simple :
- Tu vends des produits dans le monde entier. Seulement, certains produits, pour diverses raisons, ne sont pas vendables dans certains pays
- Un client, qui vient d'un pays X, commande un produit.
 
=> Ta FK va uniquement te dire que ce produit est dans la table de référence, elle ne va pas s'occuper de vérifier que le produit est effectivement vendable à ce client.
 
Un des revers de la médaille des FK, c'est justement ça : on fini par leur accorder trop de confiance, et mettre de côté certaines vérifications.
 
Selon le shéma de la base, en effet, ce test pourraît être fait par une FK (moyennant une table de jointure entre pays et produit, et recopier le pays de l'utilisateur dans sa commande, ce qui n'est pas forcément une très bonne idée lorsque tu as 400 000 références dans la base et que tu livre 80 pays, mais tu peux aussi passer par un masque binaire, ce qui va t'économiser un grand nombre d'informations. Hors une FK ne gère pas ce genre de choses.
 
Dénormaliser une base a l'avantage de rendre son modèle muet. Le développeur qui va donc devoir intervenir dessus aura une documentation à lire, qui ne traîtera pas uniquement de la base, mais des traîtements qui sont effectués dessus. A ce moment, c'est un utilisateur qui sait ce qu'il fait qui interviendra. Si le modèle est trop parlant, il regarde les flèches 2 minutes sur le modèle, et zou, il te fait péter la base parcequ'il n'a aucune idée des règles de gestion qu'il y a en plus de ces contraintes.

Je comprends ce que veux dire MagicBuzz (Arjuna)...il se trouve que je fais des études de gestion spécialisées dans les SI impliqués dans les entreprises...
 
le pb de la nature des contraintes de gestion, c que les données ont des liens très riches...je veux dire par là que pour décider qu'une base est dans un état cohérent, y'a plein de paramètres à prendre en compte...
Ce qui fait que les méchanismes de vérification du SGDB ne peuvent pas tous les prendre en compte...
 
c aussi pourquoi on fout une API de vérification, parce que c bcp plus performant de prévenir l'utilisateur a priori sans toucher à la base qui continue à tourner pour les autres, plutot que de vérouiller la base, tester si la modif est valable, la jeter si c pas bon et déverouiller la base...
 
Faut bien voir qu'un ERP ca se prend des milliers de requetes dans la tete par minutes (les données sont synchronisées tt le temps, et chaque utilisateur qui fait un ok sur une fenetre de son ERP sans le savoir fait des commit sur la base...
 
La base s'en prend tellement dans la gueule qu'il vaut mieux sortir les contraintes d'intégrité au maximum, et les tester à la source...pour ne limiter à la base que les données dont on est sur et certain...
 
Maintenant, dans le cas de Gizmo, ca se comprend aussi ce qu'il fait, mais ce ne sont pas les même contraintes...

Bon, puisque tu recommence à argumenter un sérieusement, reprenons la discussion

-->je trouve ton exemple de la réunion sans date précise très dangereux...
 
Imaginons que le gars fasse ce que tu dis, et mette sa date à NULL...mais que sa réunion aie pour contrainte d'etre le lundi 12 par ex...au moment où il le rentre, y'a de la place le lundi...
Mais ses collègues bourrent le lundi au max après...
 
Bilan : la table est incohérente, il y a une entrée qui n'a plus de place le lundi...

euh, ouais, mais là, tu rajoutes une données supplémentaire au problème qui est un échatillons de valeur possible. J'ai pris un exemple simple et sans donnée supplémentaire juste pour illustrer.  
 
Si tu veux un exemple concret qui apparait dans le système dont je m'occupe, ce sont ce que les biologistes appellent les voies métaboliques, sorte de réactions en chaines dont le déroulement se retrouve "naturellement" dans certains organismes. Problème: certaines étapes du processus sont incomplètes ou déconnectées, les biologistes acceptent en effet qu l'on parte de rien pour produire un composé chimique (le rien étant indéterminé ou inutile pour le reste). Par contre, il est interdit, au sein d'un processus d'avoir deux fois le même composé chimique, sinon on pourrait faire un raccourci. On doit donc avoir des contraintes d'unicité avec acceptation du null.

Juste un tout petit post, parcequ'il est tard et que je dois me lever tôt demain, je répondrai donc plus en détail demain.
 
A propos des SQL injection que tu cites, même si peut-être dans certains cas précis, l'insertion d'une ligne orpheline peut être intétressante (j'ai pas d'exemple en tête, mais je veux bien t'accorder que la cas puisse se présenter), dans la plupart des cas, cette techine est utilisée pour modifier/supprimer ou récupérer des informations. Donc un modèle "propre" n'empêchera pas une personne mal intentionnée de parvenir a ses besoins. Dans le pire des cas, il fait un alter pour supprimer la FK et il a le champs libre.
Cette argument me semble donc un peu hors sujet, surtout que dans tout les cas, c'est au niveaux du programme  (ici un site web qu'il y a un bug critique à corriger, le modèle des données n'est pas lui-même responsable de la faille.