Quel est l'avantage du modèle de conception wp_options?
Comme nous le savons tous, un modèle de conception fréquemment utilisé dans le code de base de données de Wordpress est l’idée de conserver les données d’un objet particulier (blog/publication/commentaire), indexées avec un nom ou une clé particuliers.
Nous voyons ce modèle utilisé dans les tableaux standard suivants:
- wp_options
- wp_commentmeta
- wp_postmeta
Autant que je sache, la décision de conception visait principalement à permettre aux auteurs de plug-in/thème de conserver facilement des données (par exemple, à l'aide de champs personnalisés) sans avoir à modifier le schéma de la base de données. Il me semble que cette approche présente peu d’avantages, car elle est nettement plus lente et rend plus difficile la mise en oeuvre de requêtes complexes.
Quels sont les autres avantages de cette approche, le cas échéant?
UPDATE: Lire des informations sur les inconvénients de cette approche:
La possibilité de stocker des paires clé-valeur abstraites sans modifier la structure de la base de données est la raison . Sans cela, WordPress perd beaucoup de sa flexibilité. Je ne peux pas parler pour les autres, mais la principale raison pour laquelle je développe au-dessus de WordPress est sa nature flexible.
Pour citer l'un de vos liens ci-dessus,
Habituellement, le raisonnement derrière ce que vous faites est que les domaines doivent être "définissables par l'utilisateur". Si tel est le cas, je ne vais même pas vous pousser à créer des tableaux à la volée ...
Il est vrai que cela oblige les requêtes à être plus complexes et un peu plus lentes, mais les avantages l'emportent largement sur les coûts. Mais, hé, tout dépend de ce que vous faites. N'utilisez pas de marteau pour cogner une vis. Si vous souhaitez toujours utiliser WordPress, mais que vous devez exécuter des requêtes complexes sur des ensembles de données stables et structurés, consultez Pods .
J'espère que cela vous aide!
L'échec le plus important de WordPress est la conception de leur base de données. Son utilisable uniquement pour les sites Web flexibles. Les sites hautes performances n'utiliseront jamais Anti-pattern comme conception de base de données en raison de problèmes de performances tels que l'indexation BASIC!