Je dois choisir la structure d'une base de données qui stockera des types de contenu (par exemple, des articles de blog, des pages, des documents, des factures, des devis, etc.) avec des champs dynamiques : par exemple, les Estimate Le type de contenu doit comporter les champs title , date y total price .
Toutefois, dans le temps, ces champs peuvent être ajoutés ou supprimés, de sorte qu'après un an, l'image de l'entreprise sera modifiée. Estimate Le type de contant peut avoir le notes champ.
Il s'agit d'une tâche courante fournie par les CMS célèbres (drupal par exemple), mais je me demande quelle est la meilleure approche pour avoir les meilleures performances et la meilleure flexibilité : Drupal, par exemple, a l'habitude d'avoir une table avec les éléments suivants basic (par exemple title ), et tous les champs secondaires sont stockés dans des sous-tableaux créés à la volée et liés au tableau principal par des clés étrangères :
table node
| id | title | ...
| 1 | First example |
table fields_node_total_price
| id | node_id | value |
| 1 | 1 | 123.45 |
table fields_node_date
| id | node_id | value |
| 1 | 1 | 12345677 |etc.
Mon point de vue est que cette approche est très flexible, mais qu'elle peut facilement poser des problèmes de performance : pour obtenir tous les champs d'un document, vous devez joindre les tables plusieurs fois, et le code lui-même doit itérer plusieurs fois pour construire la requête (mais cela ne devrait pas être un problème).
Btw multi-table est l'approche la plus utilisée donc doit avoir de nombreux inconvénients.
Je pense aux désavantages de l'utilisation d'une seule table :
| id | title | total_price | date | ec...J'ai fait quelques tests avec 5 et 50 champs supplémentaires ; les performances entre l'approche à table unique et l'approche à tables multiples sont énormes : la table unique est environ 50 fois plus rapide.
Chaque fois qu'un champ est ajouté, une colonne est ajoutée à la table Quels types de problèmes cette approche va-t-elle engendrer ?
EDITAR
Permettez-moi de vous donner quelques détails :
- L'application est encore en phase de conception, il s'agit d'une refonte complète d'une ancienne application où les numéros de champs étaient statiques.
- Nous avons fait quelques tests en simulant un objet à stocker, à la fois avec l'approche à table unique et l'approche à table multiple (en utilisant 50 champs), les résultats sont les suivants :
Temps en secondes :
Test 1° 2° 3° 4° 5° avg
1000 insert single_table 8,5687 8,6832 8,7143 8,7977 8,6906 8,69090137389466
1000 select single table LIKE '%key%' on char(250) field 1,5539 1,5540 1,5591 1,5602 1,5564 1,556705142
1000 select single table LIKE '%key%' on char(25) field 0,8848 0,8923 0,8894 0,8919 0,8888 0,889427996
1000 select single table id = $n 0,2645 0,2620 0,2645 0,2632 0,2636 0,263564462
1000 select single table integer field < $j 0,8627 0,8759 0,8673 0,8713 0,8767 0,870787334
1000 insert multi_table 446,3830 445,2843 440,8151 436,6051 446,0302 443,023531816
1000 select multi table LIKE '%key%' on char(250) field 1,7048 1,6822 1,6817 1,7041 1,6840 1,691367196
1000 select multi table LIKE '%key%' on char(25) field 0,9391 0,9365 0,9382 0,9431 0,9408 0,939536426
1000 select multi table id = $n 0,9336 0,9287 0,9349 0,9331 0,9428 0,93460784
1000 select multi table integer field < $j 2,3366 2,3260 2,3134 2,3342 2,3228 2,326600456
