Cherche un moyen de gerer des categories

[Siol]

Bonjour,

Suite a mon précédent post,

Je cherche un moyen de gerer des catégories pour une entrée dans la table "Jeux" sachant qu'une entrée peu avoir plusieurs catégories. Les catégories devront être inscrit par leur id dans les entrée de la table "Jeux".

Je ne voi pas comment faire.

Merci,

Cordialement.

Modifié 16 Mars 2006 par NorSeb

[NorSeb]

Bonjour,

Ta demande n'est pas très claire, on est pas censé connaitre ton post précédent. Tu peux en dire un peu plus sur ta structure ?

Il semble que si tu doit faire des liens multiples entre deux tables, qu'il va te falloir utiliser une table intermédiaire contenant les id des jeux et des catégories.

[Siol]

Pardon si je n'ai pas été assez clair.

J'ai une table categories avec >

| ...ID... | ...Titre... | Description |

----------------------------------------

| 1 | Action | Jeux d'action |

| 2 | Strategie | Jeux de strat |

| ... | ... | .......... |

| 14 | Sport | Jeux de sport |

Et une table Jeux :

| ...ID... | ...Titre... | Description | Categories ? |

----------------------------------------

| 1 | Arcomagic | Jeu de tir a l'arc | ? |

Ma question est pour le champs "Categories", je voudrais pouvoir inserer plusieurs categories exemple : Action et Sport avec les ID des categories donc 1 et 14.

Le probleme c'est que si j'insert dans categories "1 14" je n'arrive pas à faire resortir les categories. Cette entrée aparaitra dans la categorie 1, 14 et 4. C'est pouquoi je cherche un moyen de contourné tout sa.

Dites moi si vous ne comprenez pas quelque chose. Merci

Modifié 16 Mars 2006 par Siol

[Spidetra]

NorSeb, t'as donné la solution tu as une relation de type many-to-many entre tes 2 tables

[NorSeb]

Non là c'est clair

La solution est d'utiliser une table intermédiaire comme je te l'ai dis plus haut.

jeux_categories

------------------------------

id_jeu | id_categorie

De cette manière tu peux "mettre" autant de catégories à un jeu.

Il va de soit que le champ catégorie de la table jeu devient obsolète...

[Siol]

Merci beaucoup.

Je me demande, avec autant de tables, les pages de mon site ne risque t'elle pas de mettre un trop long moment a ce charger ?

Merci.

[NorSeb]

Les requètes seront plus complexes mais je ne pense pas que tu y vois une différence significative en terme de performances. D'autant que c'est assez classique comme structure.

Pas d'inquiétude à avoir selon moi

[Siol]

Ok bha merci beaucoup alors. Sujet clot, je peu avancer sur mon site enfin.

[Spidetra]

Pas de pb de performance si tu crée les index qui vont bien dans tes tables ( clé primaire et clé étrangère ) !

[petit-ourson]

Merci beaucoup.

Je me demande, avec autant de tables, les pages de mon site ne risque t'elle pas de mettre un trop long moment a ce charger ?

Merci.

<{POST_SNAPBACK}>

Tu en as que trois ;o)

[Siol]

Héhé et non j'en ai plus que trois. J'ai membres, commentaires, stats ect ect

J'ai un peu peur pour le chargement des pages.

Si je peu pas faire autrement. Tanpi pour les visiteurs

Modifié 16 Mars 2006 par Siol

[Compte supprimé]

Perso je n'utilise pas de tables intermédiaires de liaison, mais je "formate" correctement le champ catégories en séparant les id avec un -

ex : -1-14-

ensuite dans ma recherche sql je fais un like "%-id-%"

Je trouve cette solution plus légère.

[Siol]

hum. Pas mal pas mal j'allé partir sur l'autre idée, je vai reflechir. Je pense faire comme tu a dit jeroen.

[NorSeb]

Si je peu pas faire autrement. Tanpi pour les visiteurs 

<{POST_SNAPBACK}>

Franchement, ca m'étonnerait qu'ils y voient une différence.

[Spidetra]

hum. Pas mal pas mal j'allé partir sur l'autre idée, je vai reflechir. Je pense faire comme tu a dit jeroen.

<{POST_SNAPBACK}>

A titre perso, je ne choisirai pas cette solution !

Un SGBDR est un système Relationnel

C'est à dire un système optimisé pour gérer les relation entre les tables.

Cette optimisation passe, entre autre, par la création des bons index sur les bons champs.

1. Imagine que tu désire supprimmer la catégorie n° 1. Avec un système normalisé une simple requête va te permettre de supprimmer toutes les liaisons entre tes jeux et cette catégorie.

DELETE * FROM jeu_categorie WHERE IDCategorie = 1

Tu peux aussi gérer des triggers onDeleteCascade ou onUpdateCascade qui vont te permettre de maintenir la cohérence de ta DB. La gestion des triggers démarre avec mySQL 5.0.

2 Pour les pb de performances :

=> Il faut créer des index

=> Utilise un système de cache sur ton site

3. Commence d'abord par normaliser ta base de donnée. Ensuite, et seulement ensuite, tu peux dénormaliser ta table pour des raisons de performance ou de simplification. Il ne faut pas rester prisonier des règles de normalisation.

Je ne sais pas si tu es en entreprise ou pas, mais essaye de prendre des bonnes habitudes de modélisation de tes bases de données.

[Siol]

Ok merci

[Cleden]

Pourquoi pas

| ...ID... | ...Titre... | Description | Catégorie 1 | Categorie 2 |

?

[Spidetra]

Pourquoi pas

| ...ID... | ...Titre... | Description | Catégorie 1 | Categorie 2 |

?

<{POST_SNAPBACK}>

Cette structure n'est pas adaptée à une DB performante et évolutive.

Il en met combien de champ CategorieN : 1, 2, 3, 10, plus ?

Disons qu'il en met 5.

Qu'est-ce qu'il fait le jour où un jeu à 6 catégories ?

Modifié 20 Mars 2006 par anorci

[Portekoi]

Bonjour,

Concernant la solution du 'like', ce n'est franchement pas optimisé. Sur une petite base, la différence sera minime mais s'il faut traiter des milliers d'enregistrements, le 'like' se trouve très très gourmand.

Créé des index, fais tes requêtes avec des "inner join" et tu auras des requêtes très performantes.

Le tout n'est pas d'avoir 150 tables mais plutôt d'avoir une structure cohérente et évolutive.

Portekoi

[Cleden]

Cette structure n'est pas adaptée à une DB performante et évolutive.

Il en met combien de champ CategorieN : 1, 2, 3, 10, plus ?

Disons qu'il en met 5.

Qu'est-ce qu'il fait le jour où un jeu à 6 catégories ?

<{POST_SNAPBACK}>

J'ai donné cette solution car il rechignait à créer une table suplémentaire. Il est bien évident que la solution de la table suplémentaire est la plus évolutive.

[Spidetra]

J'ai donné cette solution car il rechignait à créer une table suplémentaire. Il est bien évident que la solution de la table suplémentaire est la plus évolutive. 

<{POST_SNAPBACK}>

Tu sais, je suis un peu psycho-rigide

J'aime bien répéter, 1.000 fois le même message, quitte a passer pour un emme.....deur

Avoir une bonne structure dés le départ, c'est important pour des pb de performances et de facilité de programmation derrière.

Ensuite on tombe sur des pb qui sont bc plus dur à régler en SQL du style :

http://www.webmaster-hub.com/index.php?showtopic=22620

[Siol]

Sa serai 3 categories je pense. Mais qui pourrai évolué a ilimité.

Sa me chagrine un peu de mettre trop de tables, sa fait moins "propre", je pensai aussi que sa ralentisser le site.

[Spidetra]

Sa me chagrine un peu de mettre trop de tables, sa fait moins "propre", je pensai aussi que sa ralentisser le site.

<{POST_SNAPBACK}>

J'abandonne !

C toi qui voit

ça veut dire quoi : "ça fait moins propre"

Ce qui ralentit les SGBRD : ce sont les mauvaises conception et les mauvaises requêtes, l'absence ou la mauvaise utilisation des index, etc.