Alors c’est un copié/collé de questions que j’ai posé à un pote, donc voilà, mettez au pluriel B)
Imagine la structure suivante :
une ville appartient à un département qui appartient à un pays
un utilisateur habite une ville.
Quel interet à mettre ville,département, et pays comme clefs étrangéres dans la table utilisateur ? ça fait de la redondance d’informations… et puis il pourrait y’avoir des pbs d’intégrité non ?
On me dit qu’au niveau traitement c’est plus rapide si ,par exemple, on cherchait le pays de l’utilisateur, et qu’il n’y avait que sa ville en clef étrangére…
Allez, une autre question, j’vois que t’en veux, dont j’ai la réponse aussi, mais vu qu’on me contredit :
une table client
une table livre
dans client y’a un champ texte “id_livres_loues” avec dedans “52-2-9-42”… Faut faire une autre table normalement, non ?
Tu as raison dans les 2 cas. Ta solution est clean et surtout permet de répondre au problème de cohérence de données (intégrité référentielle, formes normales).
Ce qu’on te propose c’est du bidouillage à 2 balles inmaintenable avec des risques de perte de cohérence de données.
Ou alors il ne faut pas utiliser les bases de données relationnelles et utiliser les bases de données hiérarchiques des moyens et gros systèmes.
Pour le coup des bouquins, ouais ça me parraissait évident. Je bosse sur un site où y’a pleiiiin de choses dans ce genre…
Pour la localisation, on m’a proposé ça:
En gros, c’est à peu prés s’que j’avais décris, avec en + une FK pays dans ville. Quelqu’un pourrait-il me dire si il vaut mieux ça que ça ? Je dirais que c’est au niveau de la complexité de la requete que celui ci-dessus est meilleure, non ? (j’aurai ptéte du mieux écouter les cours de BDD avancé) (ou alors elle aurait ptéte du rendre son cours compréhensible)
Dans le 2 , si une ville change de departement (oui, c’est idiot mais c’est un exemple) : tu ne changes l’info que dans la table ville (et tous les habitants suivent)
Dans le 1, tu dois changer tous les habitants…
Attention, je parle ici de modele conceptuel (3eme formes normales et tout et tout si je me souvient bien de mes cours d’il y a 20 ans)…Apres, en tant que développeur tu vas peut etre la dégrader (et là, tout les DBA du monde me sautent dessus !)
Ben c’est ça le pb, c’est que je connais le théorique… Pour la mise en application j’me pose pas mal de question niveau rapidité d’exécution. Pasque dans le 2, ben pour trouver la ville, faudra remonter chaque table. Alors que dans le 1, non.
C’est pareil pour les histoire de FK « simulée » avec des « 3-15-78 »…
en gros, j’ai un utilisateur, qui posséde plein de chose. Ils ont crée une table « fiche utilisateur » avec tt plein de champs texte « id_trucs » « id_machins », remplis de « 2-52-78 » qui lient vers les tables « machins » et « trucs ». Alors que moi j’aurai crée une table de lien entre les 2…
ça va dépendre du sgbd que tu utilises, mais si il est suffisamment évolué tu vas pouvoir utiliser le premier modèle en mettant des triggers sur les insertions et modifications d’habitants et de villes, qui iront tous seuls comme des grands parcourir la chaine pour aller chercher les id qui vont bien en fonction de l’id ville puis de l’id département, ce qui devrait te permettre d’éviter les soucis d’incohérence.
En théorie ça peut être utile si tu cherches à optimiser à fonds l’efficacité de ta base, et que tu prévois un très très gros volume de requetes qui auront besoin, par exemple, du pays mais pas du département ni de la ville. En pratique j’ai des doutes que ce soit le cas.
Pareil que les autre, le model 2 est beaucoup plus clean.
Si tu as ce genre de chose a faire, une(des) vue qui s’occupe de faire la jointure. Pour les perf, juste bien penser a ses index. Enfin, c’est ce que je ferai dans ce cas.
ben oui mais le 2, c’est Beau. Et si tu veux eviter de remonter chaque tables (ou faire des jointures, c’est mal il parait), tu fais des Vues qui vont bien.
edit: ah merde j’avais pas vu le post de azacreel2 (qui dit pareil) B)
le sgbd que j’utilise là, c’est mysql 4. Youpi, ça gére pas les vues trigger et compagnie.
Mais merci pour vos commentaires !! Et tout ceux qui ont encore quelques choses à dire, je les invite à le faire ^^
NB :" Pasque dans le 2, ben pour trouver la ville, faudra remonter chaque table. Alors que dans le 1, non." <= il fallait lire “ben pour trouver le pays”, mais j’crois que tt l’monde a compris B)
ben mysql gerant pas les clefs etrangeres, ca implique une absence de choix… donc tu as la reponse a tes questions.
[edit] je voulais dire pas de clefs etrangeres a mettre donc redondance d’informations obligatoire…
Le modele 1 est plus simple a mettre en place mais plus complexe a maintenir… Apres c’est une question de choix de ta part de faire quelque chose de propre ou pas necessairement.
pour le probleme situe juste en dessous de mon post, je dirais (mais je suis un peu tordu) un table monde avec la table pays qui en herite en rajoutant ses propres attributs, et la table derivee qui est reliee au departement… je sais pas si ce que je dis est clair mais j’ai pas d’outils de dessin sous la main pour exprimer ce que je dis…
Ben y’a bien un choix à faire tt de même, entre mettre 3 ids ou 1 seul dans la table habitant. Si tu pouvais être plus clair.
Et sinon, petit truc marrant :
imaginons un site qui veut gérer les habitants de la france. Et puis imaginons (imaginons hein B) ), que le client veuille pouvoir aussi gérer les habitants du monde entier, mais sans autant de précision, cad pas forcément de département, pas forcément de ville.
[quote=« GloP, post:13, topic: 45950 »][quote=« Rabban, post:6, topic: 45950 »]
ça va dépendre du sgbd que tu utilises, mais si il est suffisamment évolué tu vas pouvoir utiliser le premier modèle en mettant des triggers sur les insertions et modifications d’habitants et de villes, qui iront tous seuls comme des grands parcourir la chaine pour aller chercher les id qui vont bien en fonction de l’id ville puis de l’id département, ce qui devrait te permettre d’éviter les soucis d’incohérence.[/quote]
B) B)
[/quote]
(désolé)
A la limite Rabban, que tu dises que tu crées une table pseudo-vue avec ce pseudo-SGBD qu’est MySQL4 (je parle bien du 4 là :D), OK, mais là, si tu parles d’un SGBD « suffisamment évolué pour avoir des triggers » et que tu les utilises pour faire ça, je préfère encore que le SGBD n’en ait pas du tout quand tu es dans les parages… ^^
