Discussion :

[le-roy_a]

Bonjour,

je me pose une question, on dit souvent que les tables doivent contenir le moins de champ possible. Donc j'aurais voulu savoir si c'etait une bonne idée de les divisés ainsi :

Imaginons une table produits contenants 100 champs
J'aurais voulu savoir s'il était judicieux de creer 6 tables dont l'une d'entre elle contiendrait les Fk sur les 5 autres qui se partagerait les champs ou alors creer une seule table contenant les 100 champs.(sachant que les 100 champs sont différent pour chaque produit).

[laffreuxthomas]

Si chaque champ est rempli pour chaque produit, alors à priori une table c'est le plus simple à gérer et ça prendra moins de place.

Maintenant j'imagine que les sgbd ont des limites dans leur implémentation, donc ta réponse dépend du sgbd.

[SQLpro]

A priori une table avec 100 colonnes (les champs n'existent pas en bases de données, lire : http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2) est une erreur !

Explique moi les colonnes composant cette table, je t'expliqurais pourquoi c'est une utopie...

On peut se permettre de préoptimiser une table en la découpant, si ce découpage apporte un réel confort de lecture.

Un exemple se trouve ici : http://sqlpro.developpez.com/cours/optimiser/#L5

A +

[le-roy_a]

Ben en fait je l'avais vu cette example mais le probleme c'est que dans cette example la table employee est découpée en plusieurs tables qui sont réutilisables or dans dans mon cas ce n'est pas le cas.
En fait je voudrais savoir si en terme de performance les jointures qui vont me permettre de recuperer toutes les colonnes ne vont pas etre plus couteuses que d'avoir une seule table (sans se soucier du confort de lecture).

le sgbd est un sql server standard edition.

[orafrance]

A priori une table avec 100 colonnes (les champs n'existent pas en bases de données, lire : http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2) est une erreur !

ce n'est pourtant pas rare dans les ERP particulièrement pour la finance où des tables avec énormément de montants et données sont présentes et une fragmentation de ces tables générerait des relations 1-1 et des requêtes avec beaucoup plus de jointure... si ce type de table est à éviter, ce n'est malheureusement pas toujours évident de s'en passer

[jmmolina]

En fait je voudrais savoir si en terme de performance les jointures qui vont me permettre de recuperer toutes les colonnes ne vont pas etre plus couteuses que d'avoir une seule table (sans se soucier du confort de lecture).

Il ne faut pas non plus trop se focaliser sur les performances, une bonne architecture de la base permet généralement de composer tous les problèmes qu'on peut recontrer quand une base est mal conçu, maintenance de l'application, de la base (tables corrompues...). Certes les jointures pénalisent forcément mais ce que tu perds en performances, tu le gagnes en clarté et en efficacité, toujours pour en revenir à la maintenance du système. Sinon on en serait à une table par système d'information avec des centaines de champs. Et quand on en arrive à 100 champs pour une table, il faut revooir tout la conception et refondre complètement l'application, il y a forcément un problème quelque part. Enfin j'exagère il te suffit de segmenter ta table comme quelqu'un la suggéré. Je te conseille de suivre une méthode de normalisation pour ça, identifier par exemples les doublons et créer une table pour mémoriser ces informations, puis les référencer dans d'autres tables à l'aide de clés étrangères. SQLpro en parle mieux que moi .

Pour résoudre ce problème de performances il est donc souhaitable de bien concevoir son système afin d'équilibrer sa balance optimisation et conception. Et pour faire pencher la balance du bon côté, rien de tel qu'un serveur parfaitement configuré et administré. Il existe par exemples des systèmes de cache pour améliorer drastiquement les performances d'une application, ceci afin d'éviter de recalculer des milliers de fois la même chose, un peu comme le cache d'un navigateur qui stocke temporairement les données d'une page un certain de laps afin de les restaurer rapidement sans avoir à les recharger, on retrouve les caches dans la majorité des systèmes logiciel et matériel : disque dur, lecteur CD-ROM, processeur... Et bien évidemment dans certains SGBD.