Conception de base de données PHP/MySQL pour divers/contenu variable - système modulaire

Question

J'essaie de construire (juste maintenant penser/planifier/dessiner des relations:]) petit système modulaire pour construire des sites Web de base (principalement pour simplifier les tâches courantes que nous webdesigners font régulièrement).

Je me suis retrouvé coincé dans la conception d'une base de données/idée de stocker du contenu.

1., Ce qui est principalement douloureux sur la plupart des sites Web (d'après mon expérience), ce sont des pages avec quasiment la même mise en page/skelet, avec des informations différentes - par ex. Titre, image, et ensemble d'informations - mais, faire des modèles spéciaux/modules spéciaux en cms arrive à coûter plus d'énergie que l'éditer en tant que texte - cependant, ici nous perdons un certain potentiel opérationnel - nous ne pouvons pas obtenir "seulement des titres", Parce que, CMS/système comprend tout le contenu comme un seul champ de texte

Donc, je voudrais à ces deux tables - un pour tenir l'information quelle structure le contenu a (par exemple juste la quantité variable de photos < 1; 500):], titre & texte & photo (grande) galerie &) - COMMENT - et une autre table avec tous les contenus, modules et pièces de "collections" (mon nom travaillant pour diverses informations structurées) - QU'EST-CE QUE

table module_descriptors (HOW) 
id int 
structure - *???* 

table modules (WHAT) 
id int 
module_type - @link to module_descriptors id 
content - *???* 

2., Ce que j'aime à ce sujet est - je n'ai pas besoin de beaucoup de tables - je n'aime pas les bases de données avec 6810 tables, une pour chaque module, pour sa description, pour divers. nombre à des relations de texte, ... et je n'aime pas non plus les tables avec 60 colonnes, comme content_us, content_it, category_id, parent_id. Je pense que je pourrais tenir la description de la structure et le contenu lui-même (noté le ????) Comme XML ou CSV, mais peut-être que j'essaie de réinventer la roue et de répondre à cela est caché dans un motif de conception que je n'ai pas examiné. J'espère que j'aurai du sens et que j'obtiendrai des réponses - donnez-moi votre opinion, vos avantages, vos inconvénients ... ou envoyez-moi en enfer. Merci

EDIT: Ma question est aussi: cette approche a-t-elle un sens? Est-ce que c'est éditable? N'y at-il pas quelque chose de mieux? Est-ce moral? Est-ce que les chatons ne meurent pas quand je fais ça? N'est-ce pas trop pour le serveur, Si je veux lire & comparer 30 XML tirés de DB (par exemple, je veux comparer quelque chose)? La partie technique - comment le faire - n'est qu'une partie de la question :)

Answer 1

Le motif de conception que vous avez choisi s'appelle Serialized LOB. Vous pouvez stocker certaines données de manière conventionnelle (en tant que colonnes) pour les attributs identiques pour chaque entrée. Pour les attributs qui sont variables, formatez-les en XML ou MarkDown ou tout ce que vous voulez, et stockez-le dans un BLOB de texte.

Bien sûr, vous perdez la possibilité d'utiliser des expressions SQL pour interroger des éléments individuels dans le BLOB. Tout ce que vous devez utiliser dans la recherche ou le tri doit être dans des colonnes conventionnelles.

---

Re commentaire: Si votre blob texte est en format XML, vous pouvez rechercher avec XML functions pris en charge par MySQL 5.1 et versions ultérieures. Mais cela ne peut pas bénéficier d'un index, donc cela va entraîner des recherches très lentes.

La même chose est vraie si vous essayez d'utiliser LIKE ou RLIKE avec des caractères génériques. Sans utiliser d'index, les recherches aboutissent à des analyses de table complètes.Vous pouvez également essayer d'utiliser un index MySQL FULLTEXT, mais ce n'est pas une bonne solution pour rechercher des données XML, car il ne sera pas capable de faire la différence entre le contenu du texte et les noms de balises XML et les attributs XML.

Il suffit donc d'utiliser des colonnes conventionnelles pour tous les champs que vous souhaitez rechercher ou trier. Vous serez plus heureux de cette façon. Question n °: Si vos documents nécessitent vraiment une structure variable, vous avez peu de choix. Lorsqu'il est utilisé correctement, SQL suppose que chaque ligne a la même structure (c'est-à-dire des colonnes). Vos alternatives sont:

• Single Table Inheritance ou Concrete Table Inheritance ou Class Table Inheritance
• Serialized LOB
• Non-relational databases

Certaines personnes ont recours à un antimodèle appelé entité-attribut-valeur (EAV) pour stocker des attributs variables, mais Honnêtement, n'y allez pas. Pour une histoire sur comment cela peut aller mal, lisez cet article: Bad CaRMa.