Ursego AlexTheRavenзачем огород городить с дополнительными таблицами, нарываться на лишние join'ы?А лишние таблицы и не нужны - нужна одна, в которой будут храниться наборы записей (сеты) для каждого языка. Причём таблицу даже не надо делить на партишнз - число записей в ней будет смехотворно с точки зрения современных баз данных. Просто выбираешь простым select-ом, добавляя
WHERE language = такой-то
, вот и усе дела!
Я спорил с двумя отношениями, описанными вверху, а не с одним "узким".
Впрочем, говоря "WHERE language = такой-то", вы лукавите.
SELECT category_name FROM categories WHERE category_id='10' AND language='es'
всё же несколько сложнее для человека, чем
SELECT category_name_es FROM categories WHERE category_name='books'.
К тому же, чтобы задать на 3 языках, названия, например, 10 категорий, в "узкой" таблице понадобится 30 операций и ведение цифровых Id вручную, в "широкой" - всего 10 операций. Хотя, конечно, если ввод категорий - повседневная задача, и предполагается делать для этого специальный UI - это неважно.
Ursego
<...> структура базы данных должна обеспечивать возможности расширения и изменения системы без необходимости изменять эти структуру. IMHO это верно, если точно известно, что изменения будут происходить регулярно, т.к. за универсальность надо дорого платить.
Ursego
Конечно, это не всегда возможно, но в данном случае - легко. Понадобился новый язык - добавляй набор данных для этого языка, и приложение продолжает прекрасно работать без необходимости изменения других объектов!
В любом случае, где-то в приложении в случае "узкой" таблицы надо задать что-то наподобие strLanguagePredicate="language='ru'". Ну а в случае "широкой" - strLanguageColumn="category_name_ru". И там, и здесь - динамический SQL. То на то.
Ursego
А если добавлять новые столбцы в таблицу, что само по себе нетрудно, то придётся ещё и изменять соответственно объекты (хранимые процедуры, объекты клиентской части), которые эту таблицу считывают и обрабатывают.
AlexTheRavenПросто не надо использовать SQL-операторы без явного перечисления столбцов, и компоненты (в т.ч. ORM), к-рые такие операторы используют.Этот совет верен всегда и везде.
Если пользоваться советом, который вы внизу цитаты называете верным, то описанное сверху цитаты неправильно.
UrsegoПричём не только изменять, но и тестировать каждый раз.
Добавление нового языкового набора - в любом случае повод потестировать, причём вручную. Трудности перевода, опечатки (в т.ч. трудноуловимые, в Id), кодировки...
IMHO работоспособны оба подхода. "Узкая" таблица универсальнее (особенно если предполагается делать систему более чем на 60 языках :) ), "широкая" - немного проще для использования в приложении и намного - для манипулирования вручную. А структура БД - не победитовая, менять её не сложнее и не опаснее, чем любой другой код.
