Le portail francophone de la géomatique

Bonjour,

bienvenue dans le monde de la modélisation BD ... Je dirais que votre premier choix est le bon ... Faire des tables référentielles ... ce n'est pas grave d'avoir bcp de tables , c'est normal ... La plupart des gros SI ont plusieurs centaines de tables.  Mais ensuite , vous pouvez créer des vues , tables virtuelles résultant d'une expression SQL ... QGIS adressera ces vues

Cordialement
JY

Bonjour,

Votre première idée est la bonne. Pourquoi ?

Le gain de place : en effet une valeur de type texte 'av_200' va comprendre (suivant l'encodage) 6*2 octets, soit 12 octets.
Si vous avez 1000 enregistrements qui reprennent cette valeur vous aurez 12 ko (en simplifiant).
Si vous optez pour votre idée vous aurez :
dans une table référence une ligne de type entier , texte soit : 4 octets + 12 octets , soit 16 octets, et 1000* 4 octets (dans ass_regard) soit 4 016 octets au lieu de la première solution à 12 000 octets.

L'indépendance des attributs : si demain matin la valeur 'av_200' est changée, elle devient 'av_201', avec la solution 'une table' vous avez 1000 mise à jour à faire, avec la solution 'tables référentielles' une seule mise à jour.

La solution de p.Jeremie est valable aussi mais comme il le souligne cela amène d'autres contraintes et cela complexifie les requêtes.

Bonjour à tous,

le sujet est intéressant. Pour ma part j'aime, quand c'est possible, que les clés soient porteuses d'information quitte à ce que la taille sur disque de ma table soit impactée, mais il faut dire que je ne gère pas non plus de bases gigantesques.
Les tables remplies de clés étrangères numériques me font peur (c'est peut-être aussi peu rationnel peut-être que la peur des fantômes :-) )

La place gagnée par l'utilisation d'une clé de type entier est à envisager dans l'ensemble de la base et de son utilisation, je veux dire que si vous devez mettre en place une vue matérialisée pour l'exploitation des données vous ne gagnez pas de place.

Dans votre cas et dans mon contexte de travail, si vous ne souhaitez pas utiliser de type énuméré, j'utiliserai aussi une table "référentielle" type_fonte mais contenant comme clé primaire les valeurs 'av200', 'tv650', 'WV680'. Vous contrôlez ainsi l'intégrité de vos données, sans pour autant devoir faire de jointure lors de l’exploitation de vos données.

Mathieu

Avec la solution de Mathieu, selon moi il serait préférable de rendre
la contrainte de clef étrangère deferrable, dans le cas ou
il faudrait modifier une valeur dans la table référence.

Bonjour,

C'est pas une histoire de fantômes
Et je comprends parfaitement.

Pour ma part je dissocie toujours la partie logique du MCD des autres. Si on respecte quelques règles simples de nommage, la traduction en langage naturel est plus simple. La règle que j'applique :
nom_table avec id_nom_table : PK, si nécessaire ptr_nom_table : FK
Il faut pas essayer d'y voir des nombres (des instance des classes) mais une relation entre noms (relation entre classes).

Un regard contient un réseau de type X et une fonte de type Y  (j'y connais rien)
regard coté n
réseau coté 1
fonte coté 1
deux liaisons : réseaux 1 -> n regard ET fonte 1 -> n regard

Sélectionne l'identifiant, des attributs, le type de fonte, le type de réseau de tous les regards :

SELECT id_regard,toto, type_fonte.valeur,type_res.valeur FROM eau.regard,eau.type_fonte,eau.type_res
WHERE id_regard=type_fonte.ptr_regard AND type_id_regard=res.ptr_regard;


Après je suis parfaitement d'accord sur la façon d'envisager les choses en codant des infos dans les clefs c'est une autre façon de voir les choses tout aussi valable.