Bonjour à tous,
 
Je suis actuellement en train de construire une base de données sur DBDesigner4 pour un site que je souhaite réaliser en PHP et avec Mysql. J'ai construit ma base de données qui fait 30 tables. Des indexations ont été créées automatique par DBDesigner4 et j'ai édité la BD en .sql.
 
Lorsque j'importe ma base.sql dans Mysql, toutes mes tables sont créées mais un blocage se produit sur la création des index. Les noms de mes index doivent être trop long.
 
Une question me vient alors... Où est il judicieux de mettre des index dans une base de données ? C'est la première "grosse" base de données que je réalise (ou que je suis en train de réaliser) sur Mysql... Je suis plutôt habitué aux petites bases de données Access... Je vais jouer dans la cour des grands...  
 
Merci de vos conseils  

Salut,
 
je ne crois pas que la problématique des index soit différente selon les SGBD. Il s'agit de faire de la redondance (de clef) pour optimiser les mécanismes internes de monté en mémoire lors de l'exécution du sql.
 
Les index sont utils sur les tables volumineuses. En principe on choisit les clefs primaires (et les clefs étrangères des tables liées à d'autres tables : relation de type n->n). ces choix sont parfois proposés par les SGBD.
 
En fonction de l'utlisation on peut être amené à rajouter des index sur des libellés ou des codes de transco.  
 
Les requêtes qui rament doivent faire l'objet d'une analyse (explain plan sur Oracle) et l'ajout d'un index peut solutionner le problème, parfois c'est la structure de la requête qu'il faut changer. L'index peut représenter un coût à maitriser !  
 
L'index devient inutil délors que tu dois charger la totalité de la table pour traitement cas des clauses where like "%..." entre autre
 
Les Sgbd comme les applications évoluent dans le temps. C'est l'utilisation qui détermine bien souvent les améliorations à porter, même si une bonne conception permet d'éviter le pire.
 
Bon fun  
A+

Je souhaite faire un site de mutualisation de recettes (de cuisine) et ma base de données stockerait mes recettes. Ma base de données a plusieurs tables de liaison permettant par exemple de relier une recette à plusieurs ingrédient (table). Ces tables seront les plus volumineuses (à mon humble avis).
 
Pour l'instant, je n'ai pas envisager de faire une rechercher plein texte sur des champs de certaines tables. Donc, d'après ce que tu me dis, je dois mettre des index sur mes tables de liaison, je rajouterai d'autres index si nécessaire...
 
Merci de vos réponses.

Oui... et avec modération.
 
En fait même si la technique du doigt mouillé est une approche intuitive intéressante, elle ne saurait être seule d'une quelconque utilité pour estimer la volumétrie des tableset donc une stratégie d'accés.
 
On calcul scientifiquement la taille d'une table par le poids de ses lignes :
(somme des colonnes en octet) X (nbre de lignes ) + marge
 
La table d'ingrédient est une table de référence qui se stabilisera dans le temps.
 
Peut être qu'il faut éviter, dans ton cas (et pour l'avenir),  une jointure sur la table des ingrédients en dénormalisant ta table concernée...  
 
@+
 
 

Je pense voir ce que tu veux dire... En fait, j'ai fait directement le MPD et j'ai fait une table de liaison entre les ingredients et la recette (j'ai en plus une table unités (de mesure) qui vient sur cette table et j'ai un champ "quantité" ).
 
Ai-je raison de faire cette table de liaison qui grossira très vite en nombre d'enregistrements ? En taille, elle grossira beaucoup moins vite...
 
Dites-moi si je fais fausse route, car d'après ce que j'ai lu et un peu appris, ce doit être comme cela que l'on doit procéder, non ?

 
Tu as raison de faire les tables de référentielles ceux sont des entités importantes dans un modèle relationnel.  
 
Par contre, peut être qu'il est plus util de dénormaliser, dans certain cas, les tables plus centrales avec de la redondance utile (Simplification & performances) : la performance coute plus chère que l'espace.
 
@+

Mon problème est que je laisserai les internautes mettre des recettes (c'est une mutualisation...) et si je ne mets pas un certain ordre dans la saisie et ma base de données, je vais perdre pied...
 
Comme tu le sais une recette et un mélange d'ingrédients quantifiés et je voudrais pouvoir faire des recherches sur mes recettes en fonction des ingrédients.
 
Je pense à un truc, mais je ne sais pas si ca sera plus rapide en requête... J'ai une table ingrédient, une table unités et dans ma table ingrédient, j'ai un champ type mémo qui receueillera des infos "construites" à partir de la table ingrédient et de la table unités.
 
Par contre pour rechercher une recette ayant un ingrédient précis, je devrai faire une recherche plein texte sur ma table recette. Ca risque de prendre du temps, non ?
 
Je pensais également à un système XML, mais cela risque d'être plus lent...