Structure base de donnée

[BonBackLink]

Bonjour,

je suis en train de dévelloper un guide de produits. Les produits sont classés par catégories, chaque année il y a bien sur un nouveau guide avec de nouveaux produits et parfois même des nouvelles catégories.

Je suis parti sur l'option ou les produits sont rangées avec un id, l'année et divers champs. Une table catégories affecte une catégorie à chaque produit.

Lors d'une requête je sors les produits ayant l'année demandée et la catégorie demandée. Mais je me dit lorsqu'il y aura plusieurs années la table va être énorme. est ce que l'on ne peut pas optimiser les tables ?

En les scindant par année par exemple cela permettrai de chercher uniquement dans la table correspondant à l'année. Mais cela oblige à créer une nouvelle base chaque année.

Qu'en pensez vous ?

Merci.

[jcaron]

Tu vas probablement vite te rendre compte qu'il manque pas mal de choses dans ta structure. En particulier, les catégories ont souvent besoin d'une hiérarchie plutôt que juste une liste, un produit peut souvent être dans plusieurs catégories (et/ou une catégorie peut être dans plusieurs catégories "mères"). Ce n'est pas beaucoup plus compliqué, mais ça ajoute une paire de tables.

Concernant ta question, tu ne nous donnes aucune indication du nombre d'articles/catégories. Avec des index correctement établis (et utilisés), la taille de la base de devrait cependant pas changer grand chose.

Jacques.

[BonBackLink]

Merci pour ta réponse.

Pour être plus précis il y aura 100 à 500 articles par an pour environ 10 catégories. Un article appartien à une seule catégorie. On peux rechercher un article une dizaine d'année avant l'année actuelle.

J'avais pensé a faire une catégorie année et que les catégries soient une sous catégorie. Mais cela oblige chaque année à créer les catégories. Vu la taille de la table je pense qu'il ne faut peux être pas trop se casser la tête, mais je me demande si l'on ne peux pas plus optimiser qu'une simple liste d'articles classés par ID.

A plus.

[jcaron]

C'est tout petit comme base ça, tant que tu as un index qui intègre correctement l'année ça ne devrait vraiment poser aucun problème.

Je ne sais pas si des produits/catégories restent d'une année à l'autre, mais si c'est le cas, une table catégories, une table produits, et une table de jointure (colonnes: année, id catégorie, id produit) pourrait être une bonne solution...

Jacques.

[Dadou]

je penche pour la table de jointure de jacques a évoqué, et comme il le dis, ta base, c'est tout petit, elle ne va pas vite augmenter, 500 produits par an, j'ai des tables avec plusieurs millions de lignes, et pas de problèmes de perfs, tu en es très loin

[Portekoi]

Bonjour,

Je suis d'accord avec Jcaron. Soit tu mets l'année dans ta table de produits, soit tu éclates cette colonne en la mettant dans une table de croisement, Catégorie - Année - Produit.

Vu tes données, avec les index bien placés, tu n'as aucune raison d'avoir des lenteurs.

[BonBackLink]

Merci,

pour les informations. C'est toujours bon de savoir que l'on est sur la bonne voie et que l'on ne va pas le regertter plus tard.

Juste par curiosité quel est l'intéret de la table de jointure ? En fait dans mon système la jointure se fait directement dans la table produit qui contient un numéro de catégorie qui la fait pointer vers la catégorie adéquate de la table de catégories. Une table de jointure c'est intéressant si la table produit a de nombreux champ, cela evite de lire toute la table produits pour extraire les produits qui appartiennent à une categorie ? En lisant uniquement une table de jointure plus légére ? est ce bien cela ?

Merci.

Modifié 12 Septembre 2012 par BonBackLink

[Dadou]

C'est pour les produits qui restent plusieurs années ou qui font partis de plusieurs catégories, ça évite de dupliquer plusieurs fois le même produit

[BonBackLink]

Merci les gars, je viens de comprendre ce qu'était une table de jointure.

Toujours super cool pour les conseils en dévellopement webmaster hub, et vous venez de le prouver encore une fois.

Merci a plus.