Design d'une bdd / colonnes "extensibles"

[vincent.le]

Bonjour,

J'ai un sujet un peu délicat et je n'arrive pas à trouver de solution élégante.

J'ai plusieurs utilisateurs qui doivent avoir chacun une table de données, mais chaque table est personnalisée. Paul aura une table à 2 champs : date, note. Pierre aura une table à 3 champs : pays, pib, pnb.

Pour modéliser ça, j'ai deux solutions.

Solution 1 - Valeurs stockées en texte

J'aurai deux tables :
Table "etiquettes" :

Code :

1
2
3
4
5
6
+----+------+-------------+
| id | nom  | type        |
+----+------+-------------+
|  1 | Nom  | VARCHAR(50) |
|  2 | Note | INT         |
+----+------+-------------+

Table "valeurs" (tout est stocké en varchar(255))

Code :

1
2
3
4
5
6
7
8
9
10
+----+--------------+--------+------------+
| id | id_etiquette | valeur | date       |
+----+--------------+--------+------------+
|  1 |            1 | Paul   | 2011-04-21 |
|  2 |            2 | 12.5   | 2011-04-21 |
|  3 |            1 | Pierre | 2011-04-21 |
|  4 |            2 | 17     | 2011-04-21 |
|  5 |            1 | Paul   | 2011-04-22 |
|  6 |            2 | 14     | 2011-04-22 |
+----+--------------+--------+------------+

Avec un peu de PHP, je n'ai pas de mal à créer une table intermédiaire qui contiendra les données au bon format.

Solution 2 : Stockage de la valeur au bon format
J'aurai deux tables.

Table "etiquettes", avec un code pour le type (ex: 1=INT , 2=DATE, ...)

Code :

1
2
3
4
5
6
+----+------+------+
| id | nom  | type |
+----+------+------+
|  1 | Nom  |    3 |
|  2 | Note |    4 |
+----+------+------+

Table "valeurs", avec une colonne par type, seul le type qui va bien est renseigé :

Code :

1
2
3
4
5
6
7
8
9
10
+----+--------------+---------+------------+------------+
| id | id_etiquette | val_int | val_date   | val_double |
+----+--------------+---------+------------+------------+
|  0 |            1 |       3 | 0000-00-00 |          0 |
|  0 |            2 |       0 | 2011-04-21 |          0 |
|  0 |            1 |       3 | NULL       |       NULL |
|  0 |            2 |    NULL | 2011-04-22 |       NULL |
|  1 |            1 |       3 | NULL       |       NULL |
|  2 |            2 |    NULL | 2011-04-21 |       NULL |
+----+--------------+---------+------------+------------+

Et ensuite, je m'en sort plus honorablement, en requétant directement les bonnes valeurs.

Qu'en pensez vous ?

[ericd69]

Salut,
La première solution est, je pense, plus compact et directe, sachant que php est peu typé et même si tu restes en mysql

En pratique, un simple left outer join te reccupère le type et le tour et joué. Mais il serais plus intelligent de stocker le type "php" et non "mysql" vu que tu t'en sert que coté php d'après ce que tu dis pour l'instant

Sinon, tu peux tout transtyper directement sans passer par php, la liste des types étant courte et mysql ayant des versions de IF et de CASE intégrables dans SELECT.

[vincent.le]

Très sage de stocker le type PHP plutôt que MySQL !

Le "transtypage", c'est quoi ? Est-ce que c'est une grosse requête qui retourne les bon types directement, en fonction de ce qu'on lui dit ?

Par ailleurs, j'ai posté sur Stackoverflow là : http://stackoverflow.com/questions/5...atabase-design

Et ils m'ont indiqué le très bon sujet du Entity-Attribute-Value modèle.

Je vais potasser tout ça.

[ericd69]

Le transtypage c'est l'action de changer le type d'une donnée...

comme je te le dit tu peux transtyper :

• soit directement dans mysql et la tu laisses les types mysql pour une utilisation interne dans des requêtes.
• soit tu mets les types php, si tu fais tous tes traitements en php