I have to develop a CMS which will support two Language English, Arabic. This CMS will be a sort of Article Publishing site. While designing & analysis i found that some articles are more than 8000 characters in length. My table has some column as

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

If i keep PageBody as nvarchar(4000) then i a limited to 4000 characters and if i have to store Arabic version then i need 16000 bytes (As Arabic is Unicode and take 3 time more space then ASCII).

So i am only left with option of defining PageBody as nVarchar(max), This will have it downside from performance point of view. My actual question is if some data in PageBody column is less than 4000 characters will it MS SQL Store than data in inline column or separately in the database.

I looked for this on Google also but didn't find any relevant answer and how i can improve performance in such scenario.

Any suggestions for best practice for such design of multilingual CMS are welcome.

I need to Support Only two languages Arabic & English

  • Will you always have English and Arabic? Or maybe just one optional? If so, will one always be mandatory? Do you expect more languages later?
    – gbn
    Commented Dec 30, 2011 at 10:47

2 Answers 2


An nvarchar(max) value will be stored "in-row" if it is short enough.

The default behaviour can be modified using sp_tableoption, "large value types out of row" option. I wouldn't bother. The DB engine will manage this efficiently by itself.

As for design, there are several ways of doing this based on your model:

  • Will you always have both English and Arabic?
  • Can one be optional? If so, will one always be mandatory?
  • Do you expect more languages later?

1. Separate tables

That is, you can split off the separate languages into different tables.
This allows table level collations rather than column level ones

It allows allows more rows per page and more chance of in-row LOB storage


  • PageID int,
  • PageOtherInfo...

PageEnglish (note varchar may be OK here)

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


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

2. Separate rows

Or have a languageID column to support several languages.
This has the drawback that collation will be fixed for all languages which means poor sorting/filtering


  • PageID int,
  • PageOtherInfo..


  • PageID int,
  • LanguageCode,
  • PageTitle nvarchar(200),
  • PageDesc nvarchar(500),
  • PageBody nvarchar(max)
  • MS SQL Server has a fixed page size of 8KB.
  • A row is never splitted over several pages, but several rows can share a single page.
  • nvarchar(max) and other BLOB data may however be stored outside of the row/page.

This means that for everything to fit into one row, the sum of all sizes must be less than 8K. If it doesn't, SQL Server will store the BLOBs outside of the row/page.

Are the amounts of data so big that this really causes a performance problem?

As another option, you could perhaps change your databasestructure to have seperate rows for english and arabic pages, and include a language-code column instead. Then you won't have to fit both the english and the arabic text in the same row, and that would also make sense when fetching data, as you probably wouldn't need to fetch english and arabic at the same time.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.