powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Многоязычность в базе
25 сообщений из 40, страница 1 из 2
Многоязычность в базе
    #32811308
Basil R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть база товаров. Нужно локализовать все 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. на синтаксис не смотрите, не до него сейчас :) Главное - идея! :)
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32811479
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Второй способ - то что нужно

-- Tygra's --
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32811808
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
не соглаен с предыдущим оратором.
у каждого способа свои плюсы и минусы.
надо исходить из задач. например, насколько важна простота перевода? насколько важна протота добавления перевода, простота изменения?
Во втором подходе сложнее определить что не было переведено.
В первом, если не найден перевод на нужном языке легко подставить дефолтный.
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32811914
Basil R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dmitry Biryukov...
Во втором подходе сложнее определить что не было переведено.
В первом, если не найден перевод на нужном языке легко подставить дефолтный.

А почему во втором так нельзя? Для дефолтного языка ведь все descriptions будут... Не замечаю принципиальной разницы :) Запрос, возможно, посложнее будет...
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32812375
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я и не говорил о принципиальной разнице
просто для одних задач первый подход будет быстрее/легче/эфективнее/оптимальнее, а для других - второй.

Чтобы что-то сравнивать нужны критерии оценки, а вы их не привели. например "что больше 1 или 2?" - ответ единственный и всем понятен, а "что лучше шило или мыло?"... это для кого как
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814012
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Правильнее и универсальнее - вторым способом. Вот и весь ответ.

Первым способом - это только примеры в плохих книгах, либо когда пара языков и все, и никогда другие языки не добавятся.

-- Tygra's --
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814397
ллл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А как в твоем втором варианте будет происходить заполнение справочников БД?

т.е если они захотят что-то ввести им нужно будет лезть в специальную форму?
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814498
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Конечно нужно будет.
Вообще, чтобы хоть что-то куда-то "занести", нужно "лезть" в форму :)

А что, есть у кого-то проблемы с формами? Кто-то по-другому заполняет?

-- Tygra's --
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814636
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814728
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне даже и сказать нечего
Тут ... чего спорить то? Если лень написать 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 --
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814813
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry BiryukovПравильнее для кого? Универсальнее по сравнению с чем?
Нет, я не против второго способа. Но для таких заявлений надо привести критерии сравнения, по которым способ номер 2 выигрывает.

Ну а вот такие аргументы как.
1. При 2 варианте язык можно подставлять во все запросы параметрически - вернутся нужные поля. При первом варианте придется постоянно переписывать текст запроса (имя поля параметром не передашь вроде). А динамический SQL по умолчанию тормознее.
2. Добавление нового языка во 2 варианте - добавление 1 записи в справочник языков. По 1 варианту придется менять структуру БД и, скорее всего, код (серверной части и/или приложения). Т.е. в одном случае работа делается юзером, во втором админом+прогером.
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814820
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> 1. Простота перевода - способ 1 лучше подходит.

Плюс единственный: компактно. Минусы:
1. Невозможно использовать разные варианты перевода.
2. Невозможно использовать не синхронный перевод.
3. Не тривиальна организация разделения доступа.
4. Не тривиальна организация разноязычной обработки.

Вывод: вариант подходит для записной книжки с десятком таблиц.

> 4. добавление языка:
> способ1 - добавление поля

Простая операция. Особенно если таблиц штук пятьсот.

> ПыСы: Я пользуюсь способом 1.

И чего это критерий?
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814865
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
пытался перевести разговор от эмоций к цифрам, видимо не получилось
А вместо смеха и смайликов, не могли бы вы привести реальные задачи, где способ2 выигрывает у способа1? я привёл.
tygraТеперь комментируем и в мыслях думаем: где вы увидели англ и рус? А где еще штук 15?
ок. пишем вместо рус и англ - французский и испанский. Ваша реплика не аргумент.
tygraВы об чем? Какие переводчики?
Люди, которые переводят с одного языка на другой.
tygraЕсли вы не можете сделать нормальный способ работы с данными только из-за того, что они лежат не в одной таблице, а в двух - то это ваши проблемы.
Я смогу организовать любой из двух способов. Если это не критично для заказчика, который платит мне деньги, то я реализую первый (на мой взгляд более простой).
tygraАбсолютно одинаково он сработает
никак нет. давайте сравним время выполнения запроса
Код: plaintext
select * from transtable where descr_FR is null
и
Код: plaintext
1.
select * from transtable def LEFT OUTER JOIN transtable fr
ON def.descr_id=fr.descr_id where fr.descr is null and def.lang_id='def'
И это объективный критерий, в отличии от ваших смайликов

Как резюме третий раз повторяю: для выбора способа надо отталкиваться от задач. Список задач, на которых выигрывает (например по времени разработки, производительности) способ 2 в студию!
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814890
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 guest_20040621 & Серега
вот это объективная критика
в этих условиях способ 1 проигрывает.

А как быть с такой задачей: список кастомеров.
табличка: ИД, имя и адрес на разных языках.
При способе 1 я добавляю сколько нужно полей для всех языков.
При способе 2 что мне делать? неужели дублировать всю информацию по кастомеру, которая не зависит от языка? в том числе ИД....
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814908
Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
to Dmitry Biryukov: честно говоря, мне кажется, Вы спорите ради того чтобы поспорить. Я лично полностью согласен с тигра: "Первым способом - это только примеры в плохих книгах ..." - точнее не скажешь. Я не знаю ни одно мало мальски приличного примера с организацией структуры по первому типу.
Что касается последней реплики:
авторА как быть с такой задачей: список кастомеров.
табличка: ИД, имя и адрес на разных языках.
При способе 1 я добавляю сколько нужно полей для всех языков.
При способе 2 что мне делать? неужели дублировать всю информацию по кастомеру, которая не зависит от языка? в том числе ИД....
вы видимо невнимательно прочитали или не подумали над предыдущими предложениями. В отдельную языковую таблицу выносятся только поля требующие перевода. Из основной таблицы дается ссылка на таблицу перевода. Вся остальная информация не требует никакой модификации.

Andrey
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32814931
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AndreyВ отдельную языковую таблицу выносятся только поля требующие перевода. Из основной таблицы дается ссылка на таблицу перевода
Тоже вариант. Но мне легче разрабатывать и поддерживать одну таблицу, чем две. Как бы это не было неграмотно и насколько плохими бы не были книжки, которые пишут об этом.

Кстати, как многоязычность реализована в САПе?
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815026
Один
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dmitry Biryukovимхо, написать insert into ... select ... сложнее, чем в ЕМ добавить поле
и еще переписать все запрос(ы) где используется выбор различных языков
и еще договорится с репликацией, которая очень "любит", когда меняются структура таблиц
Dmitry BiryukovТоже вариант. Но мне легче разрабатывать и поддерживать одну таблицу, чем две. Это понятно. Это аргумент.
Dmitry BiryukovКстати, как многоязычность реализована в САПе? А это к чему ?

PS: вот так и появляются чудесные схемы на 5 таблиц по 500 колонок в каждой, и все NULLable, начиненные этими самыми NULL как хороший сыр дырками.
Затем вопросы "а как передать поле в запрос в качестве параметра, не писать же 20 раз IF ???"
Ну и наконец "а какое максимальное число полей может быть в таблице ??"
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815090
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Один
Dmitry BiryukovКстати, как многоязычность реализована в САПе? А это к чему?

Andrey вроде из САПа. если показалось - сори.

Один
PS: вот так и появляются чудесные схемы на 5 таблиц по 500 колонок в каждой, и все NULLable, начиненные этими самыми NULL как хороший сыр дырками.
Затем вопросы "а как передать поле в запрос в качестве параметра, не писать же 20 раз IF ???"
Ну и наконец "а какое максимальное число полей может быть в таблице ??"
Ну не надо так преувеличивать, языков-то реально в два раза меньше, а переводят "всего-то" на 10-20. Конечно же, если планируется и репликация и использование программы всеми народами мира, то только способ 2.
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815093
ЕОС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Для каждой таблицы выделяем поля, которые не содержат поля, которые нужно переводить.

называем ее ИмяТаблицы_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.
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815144
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> А как быть с такой задачей: список кастомеров.

Вам уже ответили на этот вопрос; не буду повторяться.

Странно, что Вы не задали вопрос об общем количестве таблиц: легко заметить, что при варианте, описанном здесь как второй, таблиц - практически вдвое больше начального количества. Уместно вспомнить про ограничение максимального количества таблиц в dbms.

Поэтому и существует третий вариант. ;)
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815147
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторпытался перевести разговор от эмоций к цифрам, видимо не получилось
А вместо смеха и смайликов, не могли бы вы привести реальные задачи, где способ2 выигрывает у способа1? я привёл.
Нет цифр, нет!
Пример 1 может работать там, где действительно только 2-3 языка и никогда не добавится четвертый. И еще в качестве плохой организации данных, когда языков больше трех и неизвестное количество.

авторНо мне легче разрабатывать и поддерживать одну таблицу, чем две. Как бы это не было неграмотно и насколько плохими бы не были книжки, которые пишут об этом.
О чем я и говорю.
А как же вы будете разрабатывать и поддерживать систему, в которой сотни таблиц???!!! Сделаете одну большую таблицу? :) Вот счастье будет кому-то потом материться при разгребании такого бардака. Или плюнете и уволитесь сразу, чтобы не мучиться?

-- Tygra's --
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815155
Ustazz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Решение во многом зависит от размеров и сложности конкретной задачи, а также от легкости эксплуатации. В случае, если языки будут добавляться в процессе функционирования системы, удобней вариант 2. Бывает, что требуется добавить ограниченную поддержку дополнительных языков в системе, где изначально это не планировалсь. В этом случае можем хранить в основных таблицах данные на каком то языке по-умолчанию, а данные на других языках - в отдельных таблицах: язык, статья (необязательно), значение_статьи_на_языке. Оператор, вводящий данные о новых товарах может использовать только язык по-умолчанию, переводчик же добавляет новые языки и новые статьи в словарь.

В принципе тот вид в котором данные хранатся в БД не обязательно должен совпадать с их представлением в интерфейсе пользователя.
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815702
ЕОС
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Предлогаю оценить 3 предложенных способа по простоте. Сравнивать предлогаю по следующей системе
1) Удобство SELECT( Отображение в форме, поиск)
2) Удобство INSERT ( Вставка данных пользователем)
3) Удобство DELETE
4) Удобство UPDATE
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815751
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЕОСПредлогаю оценить 3 предложенных способа по простоте. Сравнивать предлогаю по следующей системе
1) Удобство SELECT( Отображение в форме, поиск)
2) Удобство INSERT ( Вставка данных пользователем)
3) Удобство DELETE
4) Удобство UPDATE
Начинай. При сравнении учитывай, что удобство во дворе.
...
Рейтинг: 0 / 0
Многоязычность в базе
    #32815852
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tygraА как же вы будете разрабатывать и поддерживать систему, в которой сотни таблиц???!!! Сделаете одну большую таблицу? :) Вот счастье будет кому-то потом материться при разгребании такого бардака. Или плюнете и уволитесь сразу, чтобы не мучиться?
Не надо выдёргивать предложения из контекста и обобщать их на все случаи жизни.
Каждое предложение имеет смысл в своём контексте. А если вы не хотите понять чужое мнение или не можете обосновать своё, то действительно остаётся только поливать грязью "инакомыслящих" участников форума.

UstazzРешение во многом зависит от размеров и сложности конкретной задачи, а также от легкости эксплуатации
Вот и я о том же. Зачем из пушки (способ 2) стрелять по воробьям (небольшая база с тремя языками)?

СерегаНачинай. При сравнении учитывай, что удобство во дворе
Удобство - субъективный показатель. Как показывает этот тред, кому-то удобнее удвоить кол-во таблиц и использовать джойны, а кому-то добавить поля и использовать простые выражения.
То, с чем никто не будет спорить это - время разработки, время добавления языка и перевода, время получения определённого поля на заданном языке.
Вот только нет способа, который выиграл бы по всем трём показателям... (имхо конечно)
...
Рейтинг: 0 / 0
25 сообщений из 40, страница 1 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Многоязычность в базе
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]