Que diriez-vous de stocker des enregistrements uniques et leurs catégories dans une seule table
Je développe mon propre composant pour Joomla. Je sais que dans de nombreux composants, des enregistrements uniques et leurs catégories sont stockés dans différentes tables de la base de données. Mais que diriez-vous de les stocker dans une seule table en utilisant les parents? Chaque enregistrement et "catégorie" a un titre, un contenu/une description, des métadonnées, un champ parent et d'autres données en commun. Les parents pour les enregistrements sont leurs catégories et les parents pour les catégories sont leurs catégories de parents (si nécessaire). Et dans mon tableau se trouve la colonne type (= enregistrement ou = catégorie) et je peux simplement les utiliser dans mes vues. De cette façon, les requêtes SQL et le nombre de modèles/vues sont minimisés. Je peux comprendre que c’est une idée nouvelle et peut-être étrange, mais est-il bon de simplifier les choses de cette manière et quels problèmes peuvent apparaître dans l’avenir?
PDATED: Et si stocker les relations dans une telle table est une mauvaise idée, pourquoi ne pas stocker les titres, le contenu, les métadonnées et autres données en commun dans une table, mais uniquement les relations du parent (id, parent_id) dans une autre table ?
Selon la théorie SQL, une relation 1: N doit être représentée par une table. Dans ce modèle, toute requête peut parcourir les informations de manière cohérente.
En oubliant la théorie, vous pouvez stocker les valeurs de relation dans un champ, par exemple sous forme de tableau codé Json. Cependant, vous allez avoir besoin d'analyser ce "champ à valeurs multiples" pour le gérer. Dans LAMP, ce n’est pas possible dans MySQL et vous devez y accéder via PHP.
Pour explorer d'autres moyens de représenter un objet: Jooctrine - Doctrine ORM dans Joomla!
Je ne recommanderais vraiment pas cela. Joomla exécute des bases de données relationnelles (mySQL, postgre, etc.) optimisées pour gérer les tables relationnelles. Ce que vous décrivez est plus conforme à l'utilisation d'une base de données noSQL (mongo, couchdb) qui stocke des documents qui consolident souvent des données hiérarchiques. Joomla ne prend pas nativement en charge de telles bases de données et, à ce titre, je ne recommanderais pas de les utiliser conjointement avec un site Joomla, sauf en cas de nécessité absolue.
J'irais avec une conception de base de données relationnelle classique. Joomla a une table #__categories et des classes categories (et des vues, je pense) déjà configurées pour vous (consultez com_content ou com_weblinks pour voir comment elles sont utilisées). Ils ont également l'avantage d'utiliser des ensembles imbriqués plutôt qu'une simple relation parent/enfant ( http://en.wikipedia.org/wiki/Nested_set_model ).
Je testerais ensuite les requêtes générées. Je serais très surpris qu'elles soient le goulot d'étranglement de votre application. Tout d’abord, activez l’option de débogage de Joomla pour que vous puissiez voir les requêtes en cours de génération et le temps qu’elles prennent pour les exécuter. Ensuite, si vous voyez des requêtes lentes, utilisez EXPLAIN de MySQL pour déterminer ce qui se passe dans MySQL pour cette requête particulière. 9 fois sur 10 s'il y a un problème de performances, c'est qu'il manque un index à votre base de données. Utiliser EXPLAIN devrait vous aider à déterminer si tel est le cas.
Si vous voyez beaucoup de code en double entre les vues/modèles, etc., l'emplacement à gérer se trouve dans l'application elle-même et non dans la conception de la base de données. Ainsi, par exemple, vous pouvez écrire une classe de vue abstraite qui consoliderait votre code dupliqué et dont toutes les autres classes de vue hériteraient.
Pour résumer, je dirais - concevez une base de données relationnelle, faites fonctionner votre application, puis testez SI il y a un problème de vitesse. C'est toujours plus facile de réparer quelque chose qui vous inquiète à propos d'un problème théorique