Bonjour,

Je travaille sur la conception d'un intranet

Il a été décidé que la structure des tables soit dynamique je m'explique :

Le but est de stocker les noms des champs dans une table , et les valeurs correspondantes dans une autre table et une dernier tables pour stockes les noms de tables concernée par les champs.

J'avoue que j'ai jamais opté cette structure et c'est un peu nouveau pour moi

voici un petit schema

table_colonne                              
id -  champ - id_table_cible          
1       nom        1                     
2       prenom    1

t

able_valeur  
id - text_value - id_table_cible- id_colonne
1     pierre                1                     1
2     jean                 1                     1
3     LEVESQUE         1                     2

table_cible 
id  -  nom 
1      clients

voila en gros la structure voulue.

Ma question est que est ce que c'est bien optimisée tous ça , le seul but c'est d'ajouter tous simplement une ligne dans la table_colonne si on veut ajouter une autre propriété du table clients(table cible), Est ce que quelqu'un connait des script ou application ou même un tuto(URL) qui opte une même structure que j'ai décrit dessus ?


J'avoue être un peu bloqué par cette structure de table, Par avance Merci pour votre conseil et votre aide

Hello,

Hum, ALTER...

merci pour votre réponse

Mais je ne comprend pas ce que vous voulez dire par alert

ou c'est le commande alter table ??

merci

Ma question est que est ce que c'est bien optimisée tous ça , le seul but c'est d'ajouter tous simplement une ligne dans la table_colonne si on veut ajouter une autre propriété du table clients(table cible), Est ce que quelqu'un connait des script ou application ou même un tuto(URL) qui opte une même structure que j'ai décrit dessus ?

J'aurais tendance à trouver ça plutôt foireux.
Une petite liste +/- (faite à l'arrache, il doit en manquer )
Avantages :


Inconvénients :
- Tu ne peux pas gérer les clés (primaires, étrangères). Et s'il n'y a pas besoin de clés, c'est que tu utilises des tables sans liaisons, et du coup l'utilisation d'une BDD me semble inutile...

- Tu perds l'indexation des tables.
Une BDD utilise des index, qui lui permettent d'accélérer les requêtes. Par exemple, si tu indexes les dates de naissance, quand tu cherches les gens nés en 1900 le SGBDR ne va pas tout lire. Il va lire uniquement un petit fichier "index", qui lui indique les enregistrements à lire. C'est ce qui fait qu'une BDD est plus rapide qu'un fichier texte.
Avec une structure come ça, tu ne peux pas indexer tes tables. Du coup, tu perds l'intérêt d'une BDD...

- Tu complexifies les requêtes (et leur traitement). Avec une structure classique - table CLIENTS(id, nom, prenom) - il suffit de faire un SELECT nom FROM CLIENTS where id = 1 pour récupérer le nom de l'agent 1.
Avec une structure comme ça, il faut faire une jointure sur tes trois tables.

- Il faut gérer l'ajout d'un nouveau champ. Avec une structure classique, si tu rajoutes un champ (hors contraintes NOT NULL) - on va dire numero_portable, il existe pour tous les enregistrements. Du coup, si derrière tu cherches la liste des clients qui n'ont pas de portable (pour leur en assigner un, par exemple), ça se fait simplement (un SELECT pour la récupérer, un UPDATE pour mettre à jour).
Avec cette structure, il va falloir chercher dans ta table "Valeurs" les enregistrements correspondant aux noms des clients qui n'ont pas de portable (pas d'enregistrement correspondant au portable), et faire un INSERT. Je te laisse t'amuser pour faire la requête

Par curiosité, quelles sont les justifications qui ont amené à décider que la structure des tables soit dynamique ?
Il faut voir que l'ajout de "colonne" dans une table est quand-même rare. Et le gain éventuel en utilisant cette méthode est largement compensé par les pertes en consultation/modification (ce qui est quand-même le métier de base des BDD).
D'autant plus qu'on peut simplement modifier la structure d'une table avec un ALTER TABLE, comme te fais remarquer Nolem.