Discussion :

[Creepy_78]

Bonjour,

Je me pose un question peut etre stupide, mais bon. Aujourd'hui j'ai une table enorme avec des donn�es par jours/heures/applications.

Je me demande en temps de traitement des requ�tes quelles solutions est la plus rapide ?

1. Avoir une enorme table mais du coup une structure de BdeD plus "light" (moins de table (x8), donc moins de data systeme, etc...)
2. Avoir 40 tables (une par application). Dans cette situation mes tables sont plus l�g�res, mais la structure globale de la BdeD est plus grosse (plus de tables, etc..).

Je me dis que moins il y a de donn�es, plus la requ�te est rapide, mais je suppose que la structure de la BdeD joue non ?
D'ailleurs savez laquelle de ces 2 bases sera la plus "grosse" ?

Je ne suis pas certain d'�tre claire.

Merci
Chris

[Michel.Priori]

Bonjour,

Le mod�le de donn�e r�pond doit r�pondre aux besoins.
On peut le remettre en cause.
Faut juste reprendre les �l�ments qui ont �t� utilis�s lors de la conception initiale et y int�grer les nouveaux besoins.

Or la performance n'est pas un "besoin" de conception.
La juste segmentation/lotissement des donn�es en est un.

Avoir [...] une par application

Ceci sous entend que vous avez le m�me mod�le de s�curit� pour toutes les applications.

Et j'imagine, que vous avez qu'1 seul compte applicatif c�t� SGBD.
La s�curit� c'est l'application qui la garantie
... et la marmotte plie le chocolat dans le papier d'aluminium

Si tel est le cas je vous conseille de revoir vos "besoins" et d'y int�grer la s�curit�.
Ce qui vous am�nera peut �tre � concevoir une base (et non pas table) par application, qui sait ?