|
|
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Есть база товаров. Нужно локализовать все Descriptions которые в ней есть хотя бы для европейских языков. Подскажите грамотную архитектуру таблиц... У самого было 2 идеи: 1. Расширить все необходимые таблицы до вида: ------------------------------------------------------------- ID | Name | ... | Desc_EN | Desc_RU | ... Но что-то мне не очень это нравится... уж очень "негибко" получается 2. Свалить все descriptions в одну таблицу вида: Descriptions_tbl ------------------------------------------------------------- ID | PropertyID | LangLocaleName | Desc ... а в необходимых местах ссылаться на нее. И делать что-то вроде SELECT .... FROM.... WHERE LangLocaleName = sys_context('userenv', 'RUSSIAN') AND PropertyID=Descriptions_tbl.PropertyID; p.s. на синтаксис не смотрите, не до него сейчас :) Главное - идея! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2004, 11:26 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Второй способ - то что нужно -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2004, 12:07 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
не соглаен с предыдущим оратором. у каждого способа свои плюсы и минусы. надо исходить из задач. например, насколько важна простота перевода? насколько важна протота добавления перевода, простота изменения? Во втором подходе сложнее определить что не было переведено. В первом, если не найден перевод на нужном языке легко подставить дефолтный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2004, 13:34 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Dmitry Biryukov... Во втором подходе сложнее определить что не было переведено. В первом, если не найден перевод на нужном языке легко подставить дефолтный. А почему во втором так нельзя? Для дефолтного языка ведь все descriptions будут... Не замечаю принципиальной разницы :) Запрос, возможно, посложнее будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2004, 14:07 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
я и не говорил о принципиальной разнице просто для одних задач первый подход будет быстрее/легче/эфективнее/оптимальнее, а для других - второй. Чтобы что-то сравнивать нужны критерии оценки, а вы их не привели. например "что больше 1 или 2?" - ответ единственный и всем понятен, а "что лучше шило или мыло?"... это для кого как ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2004, 16:31 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Правильнее и универсальнее - вторым способом. Вот и весь ответ. Первым способом - это только примеры в плохих книгах, либо когда пара языков и все, и никогда другие языки не добавятся. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 11:40 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
А как в твоем втором варианте будет происходить заполнение справочников БД? т.е если они захотят что-то ввести им нужно будет лезть в специальную форму? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 13:45 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Конечно нужно будет. Вообще, чтобы хоть что-то куда-то "занести", нужно "лезть" в форму :) А что, есть у кого-то проблемы с формами? Кто-то по-другому заполняет? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 14:15 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
tygraПравильнее и универсальнее - вторым способом. Правильнее для кого? Универсальнее по сравнению с чем? Нет, я не против второго способа. Но для таких заявлений надо привести критерии сравнения, по которым способ номер 2 выигрывает. tygra Первым способом - это только примеры в плохих книгах, либо когда пара языков и все, и никогда другие языки не добавятся. Такое же безосновательное заявление как и первое. Чтобы спор приобрёл более объктивный характер, предлагаю набросать список задач, которые будут решаться. 1. Простота перевода - способ 1 лучше подходит. Выводим табличку с двумя полями: первое поле - англ, второе - рус. В способе 2 интерефейс можно организовать таким же образом, но скл-запрос будет сложнее, кроме того, по способу 1 можно и напрямую в таблице переводить. Конечно и для способа 2 можно напрямую в таблицу вводить, но попробуй переводчику объяснить что для каждой строки надо вводить и код языка. 2. определение непереведённых строк - скл-запрос в варианте 1 проще и быстрее работает. 3. подстановка дефолтного значения: способ1 IsNull(str_EN,str_RU) способ2 - скл-запрос посложнее этого выражения 4. добавление языка: способ1 - добавление поля способ2 - добавление записей имхо, написать insert into ... select ... сложнее, чем в ЕМ добавить поле 5. виндовс-приложения переводят с помощью библиотек ресурсов. Сам видел два варианта: в одном файле несколько таблиц строк, несколько файлов по одной таблице строк. Следовательно способ 1, легче/быстрее подогнять под приложения, которые не используют БД. ПыСы: Я пользуюсь способом 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 15:11 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Мне даже и сказать нечего Тут ... чего спорить то? Если лень написать insert вместо update, то ... упс...? И это представлять как одно из условий выбора способа? Прокоментирую только, как смогу. Но сначала вспомним вопрос: Basil RНужно локализовать все Descriptions которые в ней есть хотя бы для европейских языков . Подскажите грамотную архитектуру таблиц... Теперь комментируем и в мыслях думаем: где вы увидели англ и рус ? А где еще штук 15? автор1. Простота перевода - способ 1 лучше подходит. Выводим табличку с двумя полями: первое поле - англ, второе - рус. В способе 2 интерефейс можно организовать таким же образом, но скл-запрос будет сложнее, кроме того, по способу 1 можно и напрямую в таблице переводить. Конечно и для способа 2 можно напрямую в таблицу вводить, но попробуй переводчику объяснить что для каждой строки надо вводить и код языка. Вы об чем? Какие переводчики? Если вы не можете сделать нормальный способ работы с данными только из-за того, что они лежат не в одной таблице, а в двух - то это ваши проблемы. О чем тут говорить??? автор2. определение непереведённых строк - скл-запрос в варианте 1 проще и быстрее работает. Абсолютно одинаково он сработает, если только умеете вообще писать запросы. (ооооо...ххххх...ммммм) автор3. подстановка дефолтного значения: способ1 IsNull(str_EN,str_RU) способ2 - скл-запрос посложнее этого выражения Я вот щас умру чтоли, даже и не знаю, толи от смеха, толи от слез, а виноват кто будет.....? Ну е-мое, ну.... Вы в серьез эти доводы писали? Или просто посмешить? автор4. добавление языка: способ1 - добавление поля способ2 - добавление записей имхо, написать insert into ... select ... сложнее, чем в ЕМ добавить поле Так мы про грамотную архитектуру таблиц, или про самодеятельность, используя ЕМ? автор5. виндовс-приложения переводят с помощью библиотек ресурсов. Сам видел два варианта: в одном файле несколько таблиц строк, несколько файлов по одной таблице строк. Следовательно способ 1, легче/быстрее подогнять под приложения, которые не используют БД. Я не со злаааааа..... ............. ыыыыыыыыыыыыыыыыыыыыы............. А на велике то тоже не надо ездить - на самокате то лучше, ногами педали крутить не надо, двумя, на самокате то одной................. ЗЫ Ну честно не со зла, ну а как еще? Ведь кто и прочитать может, и поверит еще..... Кто пока не знает. Извиняюсь заранее. -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 15:46 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Dmitry BiryukovПравильнее для кого? Универсальнее по сравнению с чем? Нет, я не против второго способа. Но для таких заявлений надо привести критерии сравнения, по которым способ номер 2 выигрывает. Ну а вот такие аргументы как. 1. При 2 варианте язык можно подставлять во все запросы параметрически - вернутся нужные поля. При первом варианте придется постоянно переписывать текст запроса (имя поля параметром не передашь вроде). А динамический SQL по умолчанию тормознее. 2. Добавление нового языка во 2 варианте - добавление 1 записи в справочник языков. По 1 варианту придется менять структуру БД и, скорее всего, код (серверной части и/или приложения). Т.е. в одном случае работа делается юзером, во втором админом+прогером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 16:19 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
> 1. Простота перевода - способ 1 лучше подходит. Плюс единственный: компактно. Минусы: 1. Невозможно использовать разные варианты перевода. 2. Невозможно использовать не синхронный перевод. 3. Не тривиальна организация разделения доступа. 4. Не тривиальна организация разноязычной обработки. Вывод: вариант подходит для записной книжки с десятком таблиц. > 4. добавление языка: > способ1 - добавление поля Простая операция. Особенно если таблиц штук пятьсот. > ПыСы: Я пользуюсь способом 1. И чего это критерий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 16:21 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
пытался перевести разговор от эмоций к цифрам, видимо не получилось А вместо смеха и смайликов, не могли бы вы привести реальные задачи, где способ2 выигрывает у способа1? я привёл. tygraТеперь комментируем и в мыслях думаем: где вы увидели англ и рус? А где еще штук 15? ок. пишем вместо рус и англ - французский и испанский. Ваша реплика не аргумент. tygraВы об чем? Какие переводчики? Люди, которые переводят с одного языка на другой. tygraЕсли вы не можете сделать нормальный способ работы с данными только из-за того, что они лежат не в одной таблице, а в двух - то это ваши проблемы. Я смогу организовать любой из двух способов. Если это не критично для заказчика, который платит мне деньги, то я реализую первый (на мой взгляд более простой). tygraАбсолютно одинаково он сработает никак нет. давайте сравним время выполнения запроса Код: plaintext Код: plaintext 1. Как резюме третий раз повторяю: для выбора способа надо отталкиваться от задач. Список задач, на которых выигрывает (например по времени разработки, производительности) способ 2 в студию! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 16:34 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
2 guest_20040621 & Серега вот это объективная критика в этих условиях способ 1 проигрывает. А как быть с такой задачей: список кастомеров. табличка: ИД, имя и адрес на разных языках. При способе 1 я добавляю сколько нужно полей для всех языков. При способе 2 что мне делать? неужели дублировать всю информацию по кастомеру, которая не зависит от языка? в том числе ИД.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 16:41 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
to Dmitry Biryukov: честно говоря, мне кажется, Вы спорите ради того чтобы поспорить. Я лично полностью согласен с тигра: "Первым способом - это только примеры в плохих книгах ..." - точнее не скажешь. Я не знаю ни одно мало мальски приличного примера с организацией структуры по первому типу. Что касается последней реплики: авторА как быть с такой задачей: список кастомеров. табличка: ИД, имя и адрес на разных языках. При способе 1 я добавляю сколько нужно полей для всех языков. При способе 2 что мне делать? неужели дублировать всю информацию по кастомеру, которая не зависит от языка? в том числе ИД.... вы видимо невнимательно прочитали или не подумали над предыдущими предложениями. В отдельную языковую таблицу выносятся только поля требующие перевода. Из основной таблицы дается ссылка на таблицу перевода. Вся остальная информация не требует никакой модификации. Andrey ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 16:47 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
AndreyВ отдельную языковую таблицу выносятся только поля требующие перевода. Из основной таблицы дается ссылка на таблицу перевода Тоже вариант. Но мне легче разрабатывать и поддерживать одну таблицу, чем две. Как бы это не было неграмотно и насколько плохими бы не были книжки, которые пишут об этом. Кстати, как многоязычность реализована в САПе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 16:55 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Dmitry Biryukovимхо, написать insert into ... select ... сложнее, чем в ЕМ добавить поле и еще переписать все запрос(ы) где используется выбор различных языков и еще договорится с репликацией, которая очень "любит", когда меняются структура таблиц Dmitry BiryukovТоже вариант. Но мне легче разрабатывать и поддерживать одну таблицу, чем две. Это понятно. Это аргумент. Dmitry BiryukovКстати, как многоязычность реализована в САПе? А это к чему ? PS: вот так и появляются чудесные схемы на 5 таблиц по 500 колонок в каждой, и все NULLable, начиненные этими самыми NULL как хороший сыр дырками. Затем вопросы "а как передать поле в запрос в качестве параметра, не писать же 20 раз IF ???" Ну и наконец "а какое максимальное число полей может быть в таблице ??" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 17:28 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Один Dmitry BiryukovКстати, как многоязычность реализована в САПе? А это к чему? Andrey вроде из САПа. если показалось - сори. Один PS: вот так и появляются чудесные схемы на 5 таблиц по 500 колонок в каждой, и все NULLable, начиненные этими самыми NULL как хороший сыр дырками. Затем вопросы "а как передать поле в запрос в качестве параметра, не писать же 20 раз IF ???" Ну и наконец "а какое максимальное число полей может быть в таблице ??" Ну не надо так преувеличивать, языков-то реально в два раза меньше, а переводят "всего-то" на 10-20. Конечно же, если планируется и репликация и использование программы всеми народами мира, то только способ 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 17:48 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Для каждой таблицы выделяем поля, которые не содержат поля, которые нужно переводить. называем ее ИмяТаблицы_B.(B от слова BASE) Поля которые нужно переводить собираем в другую таблицу называем ее ИмяТаблицы_TL(TL от слова TRANSLATE) и в ней делаем поле LANGUAGE. Далее пишем View select .. from ИмяТаблицы_B B , ИмяТаблицы_TL TL where B.ID = TL.ID and LANGUAGE = userenv('LANG') и все формы стоим на этих view. PS такой подход используется в OEBS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 17:48 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
> А как быть с такой задачей: список кастомеров. Вам уже ответили на этот вопрос; не буду повторяться. Странно, что Вы не задали вопрос об общем количестве таблиц: легко заметить, что при варианте, описанном здесь как второй, таблиц - практически вдвое больше начального количества. Уместно вспомнить про ограничение максимального количества таблиц в dbms. Поэтому и существует третий вариант. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 18:06 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
авторпытался перевести разговор от эмоций к цифрам, видимо не получилось А вместо смеха и смайликов, не могли бы вы привести реальные задачи, где способ2 выигрывает у способа1? я привёл. Нет цифр, нет! Пример 1 может работать там, где действительно только 2-3 языка и никогда не добавится четвертый. И еще в качестве плохой организации данных, когда языков больше трех и неизвестное количество. авторНо мне легче разрабатывать и поддерживать одну таблицу, чем две. Как бы это не было неграмотно и насколько плохими бы не были книжки, которые пишут об этом. О чем я и говорю. А как же вы будете разрабатывать и поддерживать систему, в которой сотни таблиц???!!! Сделаете одну большую таблицу? :) Вот счастье будет кому-то потом материться при разгребании такого бардака. Или плюнете и уволитесь сразу, чтобы не мучиться? -- Tygra's -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 18:08 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Решение во многом зависит от размеров и сложности конкретной задачи, а также от легкости эксплуатации. В случае, если языки будут добавляться в процессе функционирования системы, удобней вариант 2. Бывает, что требуется добавить ограниченную поддержку дополнительных языков в системе, где изначально это не планировалсь. В этом случае можем хранить в основных таблицах данные на каком то языке по-умолчанию, а данные на других языках - в отдельных таблицах: язык, статья (необязательно), значение_статьи_на_языке. Оператор, вводящий данные о новых товарах может использовать только язык по-умолчанию, переводчик же добавляет новые языки и новые статьи в словарь. В принципе тот вид в котором данные хранатся в БД не обязательно должен совпадать с их представлением в интерфейсе пользователя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2004, 18:14 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
Предлогаю оценить 3 предложенных способа по простоте. Сравнивать предлогаю по следующей системе 1) Удобство SELECT( Отображение в форме, поиск) 2) Удобство INSERT ( Вставка данных пользователем) 3) Удобство DELETE 4) Удобство UPDATE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2004, 09:40 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
ЕОСПредлогаю оценить 3 предложенных способа по простоте. Сравнивать предлогаю по следующей системе 1) Удобство SELECT( Отображение в форме, поиск) 2) Удобство INSERT ( Вставка данных пользователем) 3) Удобство DELETE 4) Удобство UPDATE Начинай. При сравнении учитывай, что удобство во дворе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2004, 10:00 |
|
||
|
Многоязычность в базе
|
|||
|---|---|---|---|
|
#18+
tygraА как же вы будете разрабатывать и поддерживать систему, в которой сотни таблиц???!!! Сделаете одну большую таблицу? :) Вот счастье будет кому-то потом материться при разгребании такого бардака. Или плюнете и уволитесь сразу, чтобы не мучиться? Не надо выдёргивать предложения из контекста и обобщать их на все случаи жизни. Каждое предложение имеет смысл в своём контексте. А если вы не хотите понять чужое мнение или не можете обосновать своё, то действительно остаётся только поливать грязью "инакомыслящих" участников форума. UstazzРешение во многом зависит от размеров и сложности конкретной задачи, а также от легкости эксплуатации Вот и я о том же. Зачем из пушки (способ 2) стрелять по воробьям (небольшая база с тремя языками)? СерегаНачинай. При сравнении учитывай, что удобство во дворе Удобство - субъективный показатель. Как показывает этот тред, кому-то удобнее удвоить кол-во таблиц и использовать джойны, а кому-то добавить поля и использовать простые выражения. То, с чем никто не будет спорить это - время разработки, время добавления языка и перевода, время получения определённого поля на заданном языке. Вот только нет способа, который выиграл бы по всем трём показателям... (имхо конечно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2004, 10:32 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32815852&tid=1541388]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 375ms |

| 0 / 0 |
