Optimisation tables dans ma BDD

[shelko]

Bonjour,
Je suis en train de réaliser un script de petites annonces et je réfléchissais à l'aménagement de ma BDD pour ce qui concerne les annonces et je me demandais:

-Vaut il mieux avoir une table contenant les annonces par catégorie (immobilier, emploi... )
-Vaut il mieux avoir une table globale contenant toutes les annonces avec un champ de catégorie.

Sachant que chaque catégorie aura des champ commun et des champs différents.

Car au début celà ne changera pas grand chose je pense mais avec quelques millier d'annonce la différence ce fera peut être sentir.

Je vous remercie d'avance

[ced]

Bonjour,

La question est bien : soit une table par catégorie pour les annonces (hypothèse 1), soit une seule table pour toutes les annonces avec un champ catégorie dedans ? C'est bien ça ?
Dans ce cas, je conseille la seconde solution, qui évite d'avoir à toucher au schéma de la base de données le jour où on doit ajouter une catégorie .

ced

[shelko]

J'avais pensé à ça aussi mais j'ai vu que sur certains "gros" site les administrateur mysql commencent à partitionner les tables de façon à gagner en resources.
Dont c'est pour celà que je me posais la question, car un site de petites annonce qui tourne pas trop mal c'est quelques centaines d'annonces par jour donc au bout d'un moment je pense que l'optimisation de la BDD est importante non ?

[Maximilian]

Salut,

Je vois différentes approches qui peuvent te convenir plus ou moins selon ce que tu veux faire. Grosso modo :

• Approche 1 table par catégorie d'annonce :
  
  + Performances accrues pour les requêtes qui ne concernent qu'un type d'annonce.
  + Séparation claire des secteurs (immobilier, emploi...) => on peut même prévoir une appli différente par secteur avec chacune sa table/base.
  - Complexité lorsqu'on essaie d'obtenir des données consolidées sur tous les types d'annonces (ex : 10 dernières annonces tous secteurs confondus...)
  - Rigidité du système lorsqu'on ajoute/supprime un secteur => nécessité d'un DDL CREATE/DROP TABLE, on casse le modèle de données.

• Approche plus normalisée avec 1 table annonce et 1 table type d'annonce :
  
  annonce (id_annonce, id_type, col1, col2, col3_specifique_emploi, col4_specifique_immo...)
  type_annonce(id_type, description)
  
  + Souplesse d'ajout des types d'annonces (INSERT dans type_annonce et éventuellement colonnes spécifiques à ajouter dans annonce)
  - Perte d'espace pour les colonnes spécifiques non remplies
  - Nécessité de jointures entre type_annonce et annonce

• Approche "méta-données" avec 1 table listant les caractéristiques d'une annonce :
  
  annonce (id_annonce, id_type, auteur)
  type_annonce(id_type, description)
  type_caracteristique(id_type, id_caracteristique)
  caracteristique(id_caracteristique, nom)
  caracteristique_annonce(id_caracteristique, id_annonce, valeur)
  
  + Souplesse d'ajout de types d'annonces et de caractéristiques d'une annonce
  + Pas de perte d'espace car par de colonnes "en dur" spécifiques à un type d'annonce
  - Complexité accrue des requêtes SELECT, UPDATE... avec beaucoup de jointures
  
  cf http://sqlpro.developpez.com/cours/m...n/metadonnees/

• Approche "objet" privilégiant l'héritage :
  
  annonce(id_annonce, type_annonce, auteur...)
  annonce_immo(id_annonce, col_specifique_immo1, col_specifique_immo2...)
  annonce_emploi(id_annonce, col_specifique_emploi1...)
  
  + Tous les avantages de la solution 1 avec en plus une facilité de mapping relationnel/objet (si c'est le cas dans ton appli).
  - Tous les inconvénients de la solution 1 sauf pour la consolidation car il existe une table générale des annonces (la table mère)

A cela se rajoute la notion de partitionnement apparue dans MySQL 5.1 et qui peut améliorer sensiblement les performances. Ici on pourrait partitionner par type d'annonce par exemple.