Discussion :

[startout]

Bonjour,

J'ai vu qu'il est possible de créer des tables imbriquées dans de nombreux SGBD.
L'exemple typique que j'ai trouvé est la commande avec ses lignes de commande.
Ma question est la suivante :
Est-il préférable d'utiliser cette technique de table imbriquée ou est-ce préférable d'utiliser la bonne vieille technique. C'est à dire créer une relation entre la table commande et ligne de commande ?

En gros ce que j'aimerais savoir c'est les avantages et inconvénient des tables imbriqué.

Merci de votre aide.
Startout

[jmguiche]

Avec les table imbriquées, dans l'exemple commandes lignes de commandes, cela peut être galère de faire une simple statistique de vente sur un produit, en tout cas cela ne sera plus une jointure toute bête.

L'avantage des tables imbriquées peut être un avantage de performance quand on en est à compter les io et les milliemes de secondes. Quand on en est à compter les io, les tables en cluster (option de stockage) fonctionne presque aussi vite.
Par ailleurs, cela simplifie la vie quand on fait du dev objet et qu'on utilise le sgbd d'une façon un peu dégradée. ("tu comprends, aller chercher les produits d'une commande, c'est du métier, pas de la persistance, il faut donc le coder en java.net pour que cela s'execute sur le serveur d'application et pas sur le sgbd " j'exagère, mais pas beaucoup).

Personnelement, je ne l'ai laissé utiliser qu'une fois lors d'une recherche éperdue de performances. Je ne suis pas persuadé que le jeu en vallait la chandelle, le gain, sans être négligeable, était peut être superflux. Mais c'est fait...

Bref, si tu ne sais pas à quoi cela pourrait te servir, c'est probablement parce que cela ne te servira pas.

[startout]

Merci bp.
Je vais tester mais pas trop insister la-dessus.
Garder en mémoire cette possibilité sans plus.

[SQLpro]

Contrairement à ce qui vous a été dit, les "tables imbriquées" en fait une colonne de type table, n'est franchement pas optimal sauf dans de très rares cas.

En effet le seul cas pour lequel cela peut être un gain, c'est le cas dans lequel la colonne table est systématiquement toujours lues dans toutes les requêtes portant sur la table. Or dans votre exemple c'est loin d'être le cas.

Il faut comprendre que les SGBDR travaillent exclusivement en mémoire. En principe il ne devrait jamais y avoir lecture du disque, mais simplement les écritures. Malheureusement les mémoires vives ne sont pas infinies.
Or en "gonflant" artificiellement votre table en y imbriquant une autre, vous augmentez le volume de chaque ligne, donc le volume de la table et par conséquent à mémoire constante vous diminuez la mise en cache des données dans la RAM !

De fait, vous arriverez tôt ou tard avec cette conception à une optimisation bien moindre que la forme classique, par le simple fait qu'il faudra paginer plus (entre la RAM et le disque) pour lire moins...

A +