architecture de donnée

Bonjour,

Ma structure actuelle fonctionne mais ne semble pas efficace au niveau performance.

Voilà mon soucis, peut-être que l'un d'entre vous a déjà fait face à cette situation et connaît un bon design pattern.

J'ai une arborescence de catégories assez grande et de nouvelles catégories sont ajoutées avec le temps.

J'ai trois tables:

Citation:

---

- users
- categories
- categoriesToUsers (où je stocke des données, ex: score de l'utilisateur pour cette catégorie)

---

Je me demandais si il y a avait un moyen autre que d'utiliser une table de jointure entre catégorie et users pour stocker les données relative à l'association d'un utilisateur et d'une catégorie sachant que je dois avoir un enregistrement 'categoriesToUsers' pour chaque combinaison de utilisateur-categorie.

Etant donné que j'ai souvent besoin des données stockées dans categoriesUsers. Je vais vite avoir un problème de performance. Avec 100 catégories et 10 000 utilisateurs, j'aurais 100*10 000 soit 1 000 000 d'enregistrements dans categoriesToUsers.

Bien au contraire, ton schéma de base de données m'a l'air correct. Si la cardinalité entre les utilisateurs et les catégories est bien n-m (un utilisateur utilise plusieurs catégories et une catégories peut être attachée à plusieurs utilisateurs) alors tu as besoin d'une table de jointure.

Si tu as des problèmes de performances, regarde du coté de ton code et tente d'optimiser avec des requêtes préparées par exemple.
Une autre piste pourrait être de créer des profils d'utilisateurs afin de factoriser leurs droits (admin, user, super-user etc.) ce qui réduirait significativement le nombre d'enregistrement dans la table de jointure.

Je ne sais pas comment tu fais tes requetes ni la structure de tes tables mais tu dois effectuer des jointures pour récupérer des données, je te fais un exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

create table users ( id bigint(25) not null auto increment, name varchar(45) not null, /* ajouter ici d'autres champs */ primary key (id) );   create table categories ( id bigint(25) not null auto increment, name varchar(45) not null, /* ajouter ici d'autres champs */ primary key id );   create table users_has_categories ( users_id bigint(25) not null, categories_id bigint(25) not null, primary key (users_id, categories_id) );

---

Et une requete qui donnerai pour un utilisateur (connu par son id) toutes les categories auxquelles il a accès :

Code:

---

1 2	SELECT c.name FROM categories AS c JOIN users_has_categories AS uhc ON (uhc.categories.id=c.id AND uhc.users_id=:user_id);

---

Renseigne-toi auprès de MySQL: http://dev.mysql.com/doc/refman/5.0/en/join.html

Remarque, tu n'as pas à t'effrayer d'avoir un million d'entrées dans une table, si elle est correcte (au sens conception, c'est à dire qu'elle réponds à la définition de la 3NF) et qu'elle porte les bons index/clés, l'indexation de son contenu se fera rapidement. Je te rappelle qu'une base de données c'est fait pour ça à la base.

Merci, çà confirme ma première intuition. Je voulais être sûr que le schéma était le bon car contrairement à mes jointures classiques, chaque utilisateur est lié à la totalité des catégories et pas seulement une partie d'entre elles.

Citation:

---

Envoyé par hackiles

Merci, çà confirme ma première intuition. Je voulais être sûr que le schéma était le bon car contrairement à mes jointures classiques, chaque utilisateur est lié à la totalité des catégories et pas seulement une partie d'entre elles.

---

par souci de perf tu peux aussi indexer des champs spécifiques de users_has_categories qui sont souvent utilisés en lecture. De plus il faut veiller à faire si possible ses jointures seulement sur des int (plus rapides)

Par ailleurs, le choix de ton moteur de stockage mysql aura un effet décisif sur les performances.
Par exemple, le moteur myisam est très rapide et très peu gourmand en mémoire mais ne permet ni les transactions ni les contraintes.
Le moteur innodb en revanche supporte les transactions et les contraines au prix d'un usage mémoire un poil plus lourd et des performances pures moindres.

Cela étant, ce qui aura le plus d'impact c'est l'optimisation de ton schéma et de tes requêtes. J'ai pas vraiment le temps de te fournir un cours sur la question mais tu peux déjà aller regarder par là : http://en.wikipedia.org/wiki/Boyce-Codd_normal_form
Si tu as tout ton modèle en BCNF, c'est déjà une grande avancée dans l'optimisation.

Merci pour les conseils !
Je vais finir de coder avec cette structure de données et ensuite je passe à l'optimisation (encore beaucoup à apprendre de ce côté:)