comment nvarchar (max) stockera-t-il les données dans la base de données sera-t-il rapide si certaines données contiennent moins de 4000 caractères?

Je dois développer un CMS qui supportera l'anglais, l'arabe en deux langues. Ce CMS sera une sorte de site de publication d'articles. Lors de la conception et de l'analyse, j'ai constaté que certains articles comptaient plus de 8 000 caractères. Ma table a une colonne comme

PageID int,
PageTitleEnglish nvarchar(200),
PageTitleArabic nvarchar(200),
PageDescEnglish nvarchar(500),
PageDescArabic nvarchar(500),
PageBodyEnglish nvarchar(max)
PageBodyArabic nvarchar(max)

Si je garde PageBody comme nvarchar (4000) alors limité à 4000 caractères et si je dois stocker la version arabe alors j'ai besoin de 16000 octets (comme l'arabe est Unicode et prend 3 fois plus d'espace que ASCII).

Il ne me reste donc que l'option de définir PageBody comme nVarchar (max) , cela aura un inconvénient du point de vue des performances. Ma véritable question est de savoir si certaines données de la colonne PageBody contiennent moins de 4 000 caractères, est-ce MS SQL Store que les données de la colonne en ligne ou séparément dans la base de données.

J'ai également cherché cela sur Google, mais je n'ai trouvé aucune réponse pertinente ni comment améliorer les performances dans un tel scénario.

Toute suggestion de meilleure pratique pour une telle conception de CMS multilingue est la bienvenue.

Je dois prendre en charge seulement deux langues arabe et anglais

Une nvarchar(max)valeur sera stockée " en ligne " si elle est suffisamment courte.

Le comportement par défaut peut être modifié à l'aide de sp_tableoption , option "types de grande valeur hors ligne". Je ne m'embêterais pas. Le moteur de base de données le gérera efficacement de lui-même.

En ce qui concerne la conception, il existe plusieurs façons de le faire en fonction de votre modèle:

• Aurez-vous toujours l'anglais et l'arabe?
• Peut-on être facultatif? Si oui, sera-t-il toujours obligatoire?
• Vous attendez plus de langues plus tard?

1. Tableaux séparés

Autrement dit, vous pouvez diviser les langues distinctes en différents tableaux.
Cela permet des classements au niveau de la table plutôt que ceux au niveau de la colonne

Il permet plus de lignes par page et plus de chances de stockage LOB en ligne

PageParent

• PageID int,
• PageAutreInfo ...

PageEnglish (notez que varchar peut être OK ici)

• PageID int,
• PageTitleEnglish varchar (200),
• PageDescEnglish varchar (500),
• PageBodyEnglish varchar (max)

PageArabic

• PageID int,
• PageTitleArabic nvarchar (200),
• PageDescArabic nvarchar (500),
• PageBodyArabic nvarchar (max)

2. Lignes séparées

Ou avoir une colonne languageID pour prendre en charge plusieurs langues.
Cela présente l'inconvénient que le classement sera corrigé pour toutes les langues, ce qui signifie un mauvais tri / filtrage

PageParent

• PageID int,
• PageOtherInfo ..

Page

• PageID int,
• LanguageCode,
• PageTitle nvarchar (200),
• PageDesc nvarchar (500),
• PageBody nvarchar (max)

• MS SQL Server a une taille de page fixe de 8 Ko.
• Une ligne n'est jamais fractionnée sur plusieurs pages, mais plusieurs lignes peuvent partager une seule page.
• nvarchar (max) et d'autres données BLOB peuvent cependant être stockées en dehors de la ligne / page.

Cela signifie que pour que tout rentre dans une seule rangée, la somme de toutes les tailles doit être inférieure à 8K. Si ce n'est pas le cas, SQL Server stockera les BLOB en dehors de la ligne / page.

Les quantités de données sont-elles si importantes que cela cause vraiment un problème de performances?

Comme autre option, vous pouvez peut-être modifier votre structure de base de données pour avoir des lignes séparées pour les pages anglais et arabe, et inclure une colonne de code de langue à la place. Ensuite, vous n'aurez pas à ajuster le texte anglais et arabe sur la même ligne, et cela aurait également un sens lors de la récupération des données, car vous n'auriez probablement pas besoin de récupérer l'anglais et l'arabe en même temps.