Discussion :

[chris0938]

Bonjour,
je travaille actuellement sur Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 et on m'a demander de revoir l'architecture de la base avec différentes hypothèses dont celle ci:
est ce mieux a votre avis d'avoir beaucoup de table avec peu d'enregistrement ou peu de table avec beaucoup d'enregistrement?

[plaineR]

Je serai tenter de dire : ça dépend...

Ca dépend : des indexes créés, des requêtes effectuées, des données stockées, ...

Avec si peu d'informations, il est difficile de te faire une réponse pertinente.

[Waldar]

La réponse dépend des MCD / MLD et uniquement des MCD / MLD.

[chris0938]

merci déjà pour vous êtes intéresser a ma question.
effectivement je donne pas beaucoup d'information car c'est pas évident d'expliquer mais actuellement la base contient 285 tables de taille différents. certaines sont utiles et on les utilises souvent d'autre non.
après la réflexion se porte sur deux hypothèse possible: 1 table par mois ou une table par objet (4000 environ objets) un objet = 24 enregistrement par jour donc 730 par mois pour un objet

[DBA_OCP]

Comme a dit WALDAR ça dépend de ton SI.
C'est l'MCD qui définit cela.

[Invité]

après la réflexion se porte sur deux hypothèse possible: 1 table par mois ou une table par objet (4000 environ objets) un objet = 24 enregistrement par jour donc 730 par mois pour un objet

Woooo !
Il me semble que la conception prend déjà une mauvaise direction. Pourquoi une table devrait dépendre d'un mois ? Pourquoi ne pas mettre cette information dans la table ?

[Pomalaix]

... actuellement la base contient 285 tables de taille différents. certaines sont utiles et on les utilises souvent d'autre non.
après la réflexion se porte sur deux hypothèse possible: 1 table par mois ou une table par objet (4000 environ objets) un objet = 24 enregistrement par jour donc 730 par mois pour un objet

Bonjour
Ce que vous dites donne l'impression qu'aucune modélisation n'a été faite !
Si l'analyse a produit un schéma avec 285 tables, c'est a priori qu'elles avaient leur utilité.
Que certaines ne soient pas utilisées est un peu suspect, mais ne pose pas de problème en soi si ça reste limité.

Quant au choix entre une table par mois et une table par objet, les deux hypothèses sont aussi mauvaises et fantaisistes l'une que l'autre.
L'analyse du réel conduit à un MCD normalisé, le MCD se dérive mécaniquement en modèle logique, qui ne donnera jamais une table par mois ou par objet.
Au niveau physique, on peut éventuellement selon le contexte (à partir de plusieurs dizaines de Go) mettre en oeuvre le partitionnement, mais il est crucial qu'aux yeux de l'utilisateur/développeur, vous ayez une seule table pour tous les objets.

Comme disait Waldar plus haut, le MCD est le point de départ.

[chris0938]

En fait je dois faire un benchmark entre Oracle Database, PostgreSQL et MySQL.

Une question qui est revenue était de savoir si c'était mieux d'avoir peu d'enregistrements mais beaucoup de tables ou peu de tables avec beaucoup d'enregistrements.

Cela n'a en fait rien à voir avec la base utilisée.

[pachot]

Bonjour,
Une table regroupe des enregistrements qui ont la même structure (colonnes), les mêmes règles métiers (contraintes) et qui sont des instances du même objet métier (entité). Il n'y a pas de notion de taille là dedans. Est-ce que cela correspond à tes 4000 objets ?
Parfois, il est interressant de séparer physiquement des enregistrements d'une même table, et c'est le partitionnement (par jour, par semaine,...).
Et si le SGBD ne supporte aps le partitionnement, alors on peut faire plusieurs tables, mais l'application doit gérer cela.
Cordialement,
Franck.