"Out of row" suffisant? [Résolu]

[Sergejack]

Bonjour.

Est-ce qu'il est plus intéressant de définir des champs de type NVARCHAR(MAX) (ou TEXT) directement dans la table même ou plutôt dans une table extérieure sachant que ce champ ne sera pas nécessaire dans la plupart des lecture de données.

Je me pose la question, car ces données sont de toute manière stockées Out of row.

Exemple :
1)
Table Client : Identitfiant, nom, prénom, biographie

VS

2)
Table Client : Identitfiant, nom, prénom
Table Biographie : ClientID, biographie


Merci.

[Sergejack]

Après plusieurs recherches, j'ai trouvé la réponse à cette question.

Si vous voulez la connaître, je vous invite à la présentation que je ferai ce vendredi 14 décembre à 10h10 à la grand place de Bruxelles (plus exactement sous le "sapin").
Je remercie mon sponsor, les boutiques de farce et attrapes "Guy Lee - Guilli" qui financeront la dite présentation.

J'espère vous y voir nombreux.

[Sergejack]

Triste nouvelle, la présentation est annulée

Apparemment mon sponsor aurait subit de fortes pressions d'une certaine Estelle Praux et s'est rétracté

Mais, bon prince, je vous donne quand même la réponse :

Avoir la valeur à même la table et out of row (désactivé par défaut, ne l'oublions pas) est plus performant.
J'aurais dû vous expliquer des trucs sur les pointeurs et le storage tempdb mais là, du coup, je n'y ai plus le coeur.

Estelle Praux, qui que tu soit, je ne te remercie pas.

[mikedavem]

Avoir la valeur à même la table et out of row (désactivé par défaut, ne l'oublions pas) est plus performant.

Pas forcément je pense.

Je précise tout d'abord que le choix des types NVARCHAR(MAX) (ou TEXT) n'ont pas du tout le même impact sur le stockage. Les types avec longueurs MAX laissent le choix à SQL Server de la manière de stocker les données (soit in-row, soit row-overflow soit LOB). Tout dépend en réalité la longueur des données insérés ou mis à jour. D'ailleurs c'est un des pièges de ce type de données car en fonction de cela les données des colonnes concernées peuvent être déplacées d'un type de stockage à un autre (consommateur en allocation et en écriture dans le journal)

Ceci étant dit prenons le cas le plus simple avec les données de la colonne biographie dans un type de stockage à part LOB :

Table Client : Identitfiant, nom, prénom, biographie

Dans le cas d'un SELECT sur les colonnes Identifiant, nom, prénom c'est relativement intéressant car du fait du pointeur 24 octets (en fonction) seuls les pages in-row seront concernés.

Prenons le cas d'une maintenance maintenant. Le fait de tout avoir dans une page peut être problématique. Les opérations de maintenance sur les types LOB ne sont pas forcément réputés pour être aussi rapides que les données in-row. Je ne rentre pas dans le détail mais avoir un partionnement vertical ici peut être intéressant surtout si on a beaucoup de volumétrie dans la colonne bibliographie et que la table principale est très sollicitée.

++