|
|
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Появилась необходимость реализовать многоязыковую поддержку. Меня интересует как в таком случае спроектировать базу. Есть таблица Articles (Id, AddedByUser, AddedDate, Title, Description, Body, ViewCount). Для поддержки многих языков есть 2 варианта 1. Articles (Id, AddedByUser, AddedDate, TitleRU, TitleEN, DescriptionRU, DescriptionEN, BodyRU, BodyEN, ViewCount). 2. Articles (Id, AddedByUser, AddedDate, ViewCount). ArticlesLocalized(Id, ArticleId, Title, Description, Body, LanguageId) Languages(Id, Name) Первый вариант проще, второй - гибче. Какой чаще используется? Какой лучше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 09:37 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Лучше по каким критериям ? Мне бы, например, 1 категорически не понравился бы в любом случае. Если заранее на 1000% (да, не на 100 а на 1000) известно, что языков два и именно те, что заложены, может быть 1 по каким-то резононам удобнее. Если хоть бы раз будет третий язык, 1 вариант просто технически не годится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 09:49 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
авторЛучше по каким критериям ? гибкость, удобство, расширяемость, простота ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 09:54 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Гибкость и расширяемость противоречат простоте. Удобство для кого ? Dba, ненавидящих динамическую генерацию SQL кода, или разработчика, которому часть наплевать на строгие ограничения и связи, мешающие заполнять формы в удобном порядке ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 10:05 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
DaroomaПервый вариант проще, второй - гибче. Какой чаще используется?Первый вариант проще только для двухязыковой поддержки. А для многоязыковой он непрост :-) Вам то что надо? DaroomaКакой лучше?Я бы выбрал второй. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 10:10 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Darooma2. Articles (Id, AddedByUser, AddedDate, ViewCount). А у вас статью на всех языках сразу добавляет один и тот же пользователь, причём одновременно?.. И статистика просмотров по ним считается "оптом"?.. И где вы только таких пользователей-полиглотов берёте?.. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 13:52 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Darooma > Лучше по каким критериям ? гибкость, удобство, расширяемость, простота Замените эти лозунги на тест-кейсы и смоделируйте работу системы. Например - 1 добавлена статья (на каком языке) 2 добавлен перевод 3 запрошена статья (без указания языка) 4 запрошены все статьи автора 5 запрошены все статьи с даты по дату 6 запрошен перевод (на определенном языке) 7 добавлена поддержка еще одного языка Для каждого случая прикинте объем работы (машинной и человеческой) и умножте на предполагаемое количество раз. Ваш вариант два неплох для варианта равномерного распределения языков, однако если статей на каком либо языке (например русском) гораздо больше остальных, есть возможность "срезать угол" и избежать одного скана. (Если предположение оказалось неверным это проигрыш, лишняя работа) Короче я предлагаю Articles (Id, AddedByUser, AddedDate, ViewCount, Title, Description, Body, LanguageId). ArticlesLocalized(Id, ArticleId, Title, Description, Body, LanguageId) Languages(Id, Name) плюс имеем лишний бонус в виде минимальной переделки существующей системы (мелочь, а приятно) Программист-Любитель Если хоть бы раз будет третий язык, 1 вариант просто технически не годится. Насчет негодится я бы поспорил, alter table никто не отменял, другое дело что такой подход имеет прорву минусов и ни одного плюса для вашего проекта (вряд ли пользователь захочет статью на ВСЕХ языках одновременно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 18:40 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Второй вариант победил. Всем спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2011, 20:02 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
интересно, а можно ли как то хранить переводы централизовано в одной табле ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2011, 15:04 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Второй вариант добавляет join к каждой выборке. 3. Languages(Id, Name) Articles (Id, LanguageId, Title, Description, Body, AddedByUser, AddedDate, ViewCount) Так не устроит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2011, 19:00 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Sergei.Agalakov, вероятно, возможна одна статья на разных языках :) Непонятно, почему на замечание Dimitry Sibiryakov обиделись :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2011, 23:47 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
advSergei.Agalakov, вероятно, возможна одна статья на разных языках :) Непонятно, почему на замечание Dimitry Sibiryakov обиделись :) Предположу, что для этого варианта имелся в виду ПК (Id, LanguageId) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2011, 11:22 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
alexeyvgadvвероятно, возможна одна статья на разных языках :) Предположу, что для этого варианта имелся в виду ПК (Id, LanguageId) В этом варианте, с двумя таблицами, статья имеет только один атрибут Id, этого может быть недостаточно. Хотя, что гадать - полную задачу мы не знаем :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2011, 11:32 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Если, в одном списке, будут присутствовать только 1 вариант - по таблице для каждого языка будет лучше по производительности. article_en (id, desc, text ...) article_ru (id, desc, text ...) article_es (id, desc, text ...) article_ua (id, desc, text ...) Если пользователь смотрит в одном списке статьи на нескольких языках (а, например, на странице статьи, ссылки на остальные варианты переводов) article (id, desc, text ..., lang_id) many_to_many: article_translation (article_id, translation_article_id, lang_id) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2011, 00:01 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
kugu, ага, и при добавлении нового языка переделывать структуру базы. Гениально. А выигрышь при грамотной организации индексов будет копеечный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2011, 00:34 |
|
||
|
Проектирование базы для многоязыкового сайта
|
|||
|---|---|---|---|
|
#18+
Тема занятная. Попробуйте тип поля array как в postgresql. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2011, 14:23 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=56&tid=1541966]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
79ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
| others: | 238ms |
| total: | 422ms |

| 0 / 0 |
