Une grand table, ou plusieurs petites ?

[Equilibrius]

Bonjour,

Après quelques recherche j'ai trouvé des posts similaires, mais comme chaque cas est différent, je me permets de recréer un post.

Aujourd’hui, étant dans un cas de figure relativement simple, je m'interroge sur le chemin à prendre pour construire ma base de données : mon application PHP gère des clients, qui ont tous une 50aine d'informations (date, num, addr, description, newsletter ...). Est-ce qu'il est plus judicieux de sectionner en plusieurs tables, par exemple créer une table "coordonnées" (pour addr, email, tel ect..) et ainsi de suite.. ou alors mettre toutes les info dans la même table (et donc avoir ~50 colonnes) ?

D'après ce que j'ai pu lire, je pense m'orienter vers la création de plusieurs table, le hic c'est que : le nombre de clients sera probablement grand (~ 300 000) et donc l'utilisation "massive" de jointures me laisse penser à une éventuelle perte de perfs suite à la croissance de la base.

Au niveau des données stockées : certaines sont susceptibles d'être utilisées par un moteur de recherche (6), d'autres en tant qu'"option" (genre newsletter, 12 en tout), et les autres représenteront du texte destiné à être simplement affiché.

Pour résumer : Grande table vs Beaucoup de Jointures = ? :$

Bonne début de semaine

[boussafi]

je t'oriente de lire un petit peu sur les langages le conception tel que merise

[kain_tn]

Bonjour,

tu peux faire des jointures tant que tu poses les bons index pour qu'elles soient optimisées. http://sqlpro.developpez.com/cours/quoi-indexer/

Après, tout dépend de l'application que tu vas avoir derrière et donc des requêtes qui seront jouées. Essaye de raisonner en termes d'entités, puis après tu pourras penser à améliorer ton modèle pour coller à ton application.

Merise peut être une bonne approche en effet.

[Equilibrius]

Bonjour, merci pour vos réponses.

je sais qu'une telle structure peut paraitre suspecte, mais : tout les champs utilisé (enfin en gros, ~90% d'entre eux) doivent être impérativement sélectionné a chaque lecture de la base. Si je segmente en plusieurs tables, chaque tables supplémentaire ajoute une jointure.. Je vais m'orienter vers une segmentation simple (en 2 talbes pour le moment) avec des bon index, merci pour le lien, j'ai de la lecture

Au niveau de l'application, c'est principalement pour faire de la lecture/recherche, la création de lignes ou leur mise à jour est beaucoup plus rare.

Bonne fin de soirée

[CinePhil]

Commence par modéliser les données de façon rigoureuse.

300 000 lignes dans une table clients, ce n'est rien du tout pour un SGBDR digne de ce nom et sur un serveur normalement dimensionné, même avec de multiples jointures sur des tables de référence.

Tu peux proposer ton modèle de données dans le forum Schéma.