Xpoint
   [напомнить пароль]

Мультиязычность, виды внутренних структур хранения данных

Метки: [без меток]
2006-07-24 18:48:17 [обр] Алексей Севрюков(2/1280)[досье]
Имеется многоязычный сайт, хочется узнать наиболее правильные и концептные решения хранения контента сайта в БД. Кто какие структуры использует, насколько удобно пользоваться, каким образом разделение устроено в админке и т.д.?
спустя 10 дней [обр] Сергей Сирик(7/737)[досье]
А насколько многоязычный? Сколько языков примерно предполагается? Многоязычность "зеркальная"? Т.е. для каждой новости например должен быть свой языковой эквивалент?
спустя 14 часов [обр] Алексей Севрюков(2/1280)[досье]
Сергей Сирик[досье] Многоязычность зеркальная. Языков - любое количество (использоваться будут в 99,9% не более трех).
спустя 5 часов [обр] Сергей Сирик(7/737)[досье]

НУ если не больше 3х, то ИМХО проще каждое поле текстовое хранить в трех экземплярах в одной таблице. Тогда можно просто и абнакновенно работать с этой самой таблицей. Типа имя1, имя2, имя3. А под 1, 2 и 3 подразумевать те языки, которые в данный момент нужны.

Или диаметрально противоположная, если мона так сказать, схема типа сущность->список свойств, когда все инфа укладывается в абсолютно однообразную структуру. Тогда достаточно добавить в свойство признак языка - и опаньки. У меня в проекте сейчас как раз такая структура используется :). Оно потенциально намного гибч первой схемы, это очевидно :). Админить инфу в такой структуре достаточно просто, если админу фиолетов дизайн админки - очень уж он регулярным получается :) А вот построить красивую формочку для сущности (в смысле что-то более сложное, чем список поле-значение сверху вниз) может быть муторно. Во втором проекте, где "красивость" форм редактирования важна, использую как раз первую схему. Ну и основным минусом такой схемы является ее тормознутость на выборках, особенно если надо реализовывать сложные связи между объектами. Оно-то реализуется, но относительно первой будет таки тормозней.

Резюмируя - что-то подсказывает мне, что это должно быть решение класса CMS :). Тама лучше первая схема. Если изначально предполагается какая-то схема кеширования (предгенерации в статику) - то лучше вторая.

спустя 55 минут [обр] Александр Лукьянов(0/781)[досье]

Мои пять копеек:

Таблица языков lang
id, name, ...

Таблица документов doc
id, parent, ..., defaultLangId, ...

Таблица контента
docId, tstamp, ... , langId, data

Связи между таблицами очевидные. Удобно тем, что можно для разных разделов задавать любой из имеющихся языков "по умолчанию", т.о. строить мультиязычность и параллельной структурой, и отдельным деревом. Можно хранить любое количество версий любого документа на любом языке.
Условное неудобство — при извлечении контента нужно учитывать, что контента на заданном языке может не быть. Ну и увеличение объема БД при хранении версий.

Мне удобно :)

В админке селект со списком версий документа (время, язык) - выбрал нужную и редактируй. Ну и пара кнопок - создать новую языковую версию, почистить историю и т.п.

спустя 6 часов [обр] Алексей Севрюков(2/1280)[досье]

Александр Лукьянов[досье] Я тоже больше склоняюсь примерно к такому варианту.

Условное неудобство — при извлечении контента нужно учитывать, что контента на заданном языке может не быть

Это уже полузеркальная версия, и в принципе даже неудобством это назвать трудно :-)

Сергей Сирик[досье] Спасибо за пост. Первый вариант отпадает сразу - неконцепт, да, он простой, элементарно реализуется и даже не нужно ничего доделывать особо в моем случае. Но у меня, например, контентных полей - 4 (а если считать еще и дополнительные - то больше). Заводить 12 полей для трех языков - уж больно много. Второй вариант пока отложу, думаю что дойду до него чуть позже, сразу не могу так перескакивать.

спустя 2 дня 11 часов [обр] Андрей Пахомов(0/310)[досье]
Алексей Севрюков[досье]
У меня была в свое время реализована структура, когда каждая таблица состоит на самом деле из двух:
в первой содержатся неязыковые параметры, а во второй - текстовые поля, идентификатор языка и номер записи из первой таблицы. Далее это все либо средствами SQL через VIEW представляется как одна таблица, либо это же делается на серверном языке (PHP,Perl и.т.д.)
Преимущества - всегда только один JOIN и легко реализуется поиск сразу по всем языковым версиям.
Минусы - приходится перед каждым изменением записи проверять, существует ли для данной языковой версии запись во второй таблице, и если нет - то делать не UPDATE а INSERT. Хотя если делать на mysql, то там можно использовать REPLACE, тогда этого недостатка быть не должно.
спустя 18 минут [обр] Алексей Севрюков(2/1280)[досье]
Андрей Пахомов[досье] Да, эта схема красивая. Мне нравится. Спасибо.
Единственная сложность возникает только с тем, что приходится работать с двумя таблицами при добавлении записей, но это в принципе того стоит.
Powered by POEM™ Engine Copyright © 2002-2005