Best-practices for localizing a SQL Server (2005/2008) database

Question

Question

I\'m sure many of you have been faced by the challenge of localizing a database backend to an application. If you\'ve not then I\'d be pretty confident in

Answer 1

I see no advantage in using the XML-columns to store the localized values. Except maybe that you have all localized versions of one item "in one place" if that's worth something to you.

I would propose to use a cultureID-column in each table that has localizable items. That way you don't need any XML-handling at all. You already have your data in a relational schema so why introduce another layer of complexity when the relational schema is perfectly capable of handling the problem?

Let's say "sv-SE" has cultureID = 1 and "en-EN" has 2.

Then your query would be modified as

SELECT *
From Product
Where Product.ID = 10 AND Product.cultureID = 1

for a swedish client.

This solution I have seen frequently in localized databases. It scales well with both number of cultures and number of datarecords. It avoids XML-parsing and processing and is easy to implement.

And another point: The XML-solution gives you a flexibility you don't need: You could for example take the "sv-SE"-value from the "Name"-column and the "en-EN"-value from the "Description"-column. However, you don't need this since your client will request only one culture at a time. Flexibility usually has a cost. In this case it is that you need to parse all columns individually while with the cultureID solution you get the whole record with all the values right for the requested culture.