Сайт, русская и английская версия, возможно будет итальянская, украинская и т.д.
Ряд объектов, связанных с публикацией на сайте, должен переводиться на языки.
база не очень большая - несколько десятков магазинов, столько же статей, адресов, страниц, новостей и прочего.

Пока рассматриваю два подхода: нормализованный и не очень.

1. Нормализованныйтакой подход: все, что должно переводиться, выводится в отдельные таблички, для каждой сущности. Например:
Language(ID)
("en")
("ru")
...

Store (ID, AddressID)
StoreLocalized(StoreID, LanguageID, Name) ключ: (StoreID, LanguageID)

Address (ID)
AddressLocalized(AddressID, LanguageID, StreetAddress) ключ: (AddressID, LanguageID)

Article(ID, Published datetime, PublishTill datetime)
ArticleLocalized(ArticleID, LaguageID, Title, Description, Body) ключ: (ArticleID, LaguageID)

Достоинства: оптимальность памяти и производительности, возможность настройки индексов, задания типов.
Недостатки: Смущает необходимость создавать кучу переводных таблиц.

2. Одна таблица для строк, с ntext или nvarchar(MAX)

LocalizedString(PropertyPath string, EntityID, LanguageID, Text nvarchar(MAX))
ключ: (PropertyPath, LanguageID, EntityID)

Article:
(1, 01.11.2008, 01.01.2009)
LocalizedString:
("Article.Title", 1, "ru", "Джинсы и шубы")
("Article.Description", 1, "ru", "Шей джинсы зимой, а шубы летом")
("Article.Body", 1, "ru", "Здесь строка до 10,000 символов")
("Article.Title", 1, "en", "Jeans and Fur")
...

Достоинство одно - в базе нет кучи языковых таблиц
Недостатки: их не счесть.

Какие еще достоинства и недостатки вариантов?
Так ли уж плохо иметь общий строковый тип с запасом (ntext, nvarchar(MAX), и смесь данных от разных сущностей в одной таблице?