Bonnes pratiques sur la modélisation de grosses tables

Bonjour,

Dans le cadre d'un système décisionnel, je vais avoir à gérer quelques grosses tables avec plusieurs millions de lignes et plusieurs centaines de champs.

Je me pose la question de l'opportunité de répartir les champs de ces tables en plusieurs table contenant un sous-ensemble des colonnes, ces tables étant reliées par une relation 1-1. Du point de vue alimentation, ça aurait du sens car les champs sont alimentés par plusieurs traitements successifs.

Votre avis sur la question ?
Est-ce qu'il peut y avoir un gain sur les performances ? Est-ce que la facilitation sur l'exploitation des tables (plus petites) peut valoir le coup par rapport à la charge supplémentaire de gestion des nouvelles tables ?

Pour info, je n'ai pas l'option de partitionnement sur la base Oracle.

Par avance merci,
Nicolas

N'étant pas un expert de la modélisation, je te conseillerai juste ce que j'ai lu plusieurs fois : plus le nombre de tables est important et plus ton modèle est résistant.
En clair : il faut éviter au maximum les tables avec trop de colonnes.

Oracle permet maintenant de créer des tables de 1000 colonnes mais cela peut avoir les inconvénients suivants :
1) redondance des enregistrements alors que seule la valeur d'un champ est différente
2) un lock est posé sur toutes les colonnes de l’enregistrement lors d'un UPDATE et cela bloque les sessions concurrentes qui voudraient updater d'autres champs du même enresgitrement
3) row chainage intra-bloc si plus de 246 colonnes
etc etc

Je crois que ça fait assez longtemps qu'Oracle permet des tables à 1000 colonnes, et effectivement c'est une fausse bonne idée.
Ça dépanne, mais côté perf on reste sur sa faim.

@DevNico, ce que vous décrivez s'appelle du partitionnement vertical, abordé ici. Je l'avais essayé il y a quelques années ça fonctionne plutôt bien. Apparemment les liens sont assez morts, mais je dois pouvoir retrouver mes bouts de code si ça vous intéresse.

Il faut découper par exemple en trois les groupes de colonnes en fonction de leur fréquence d'appel.
Par contre, comme l'indique pachot dans le sujet en lien, le gain peut être nul en fonction de l'utilisation de votre table.

Maintenant... sur des bases décisionnelles on combine plutôt du partitionning horizontal (celui de l'option que vous n'avez pas) et des index bitmaps (a priori vous n'avez pas non plus) pour avoir des bonnes performances sur un sous-ensemble de données, et de bons I/O disques avec des blocks de 32k et du multiblockread a gogo (512) pour des scans complets.

Le partitionning horizontal, même sans l'option, vous pouvez toujours le faire à la main en créant les tables une à une et en posant une vue dessus qui fait l'union.
Avec un peu de PL/SQL, vous pouvez automatiser la création des nouvelles partitions et la mise à jour de la vue.

Est-ce que vous en savez un peu plus sur ce que vous attendez en volume ?
Le nombre de lignes c'est bien, mais la taille en Go c'est au moins aussi important.

Bonjour Waldar,

Merci pour toutes ces infos sur le partitionnement vertical. :)
Donc en synthèse je retiens que ça peut avoir du sens suivant l'utilisation qu'on fait des tables. Je pense qu'on va partir là dessus.

Sinon j'ai bien la possibilité de créer des indexes bitmaps.
(Je viens même de remarquer que contrairement à ce que je disais, j'ai également la possibilité de créer des tables partitionnées -> il faut que je check les infos sur la licence qu'on a achetée...)

On estime la plus grosse table à 30Go pour l'instant.
Et on aura 4 ou 5 autres tables qui dépasseront les 10Go.

Merci,
Nicolas

30 Go ce n'est pas énorme non plus mais le partitionnement - si vous avez en effet l'option - c'est toujours intéressant à mettre en place.
Moins d'I/O, moins de ressources consommées inutilement, une machine plus disponible.