ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ваши рекомендации по структуре мультиязичности данных БД
25 сообщений из 28, страница 1 из 2
  1  все
Ваши рекомендации по структуре мультиязичности данных БД
    #37339985
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
Собственно. Заказчик просит прикрутить к уже работающему проекту мультиязычность контента.
DataBase - Oracle 11g.
Application GUI- Delphi.
Структура справочников не сложная и почти однообразная
1. Primary Key
2. Аттрибуты
3. Поле для перевода
4. Возможно еще поле и т.д.

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

1. Банально добавить поля с суффиксом языка(Field_Eng, Field_UKR). Просто в реализации но не предусматривает возможность расширения языков, в случае добавления языка нужно добавить во все таблицы по полю, переделать все вьюшки и подкоректировать все GUI модули.

2. Создать единый справочник в виде двух таблиц. В первой.
Уникальный код

Имя схемы

Имя таблицы

Имя поля

Соответственно во второй

Уникальный код

Код языка

Код PK

Перевод
Вроде красиво, но опять таки проблема делать вьюхи, нужно джоинить постоянно, и если в одной табличке более одного поля для перевода то нужно столько же джоинов. Ну в GUI можно сделать компонент который будет сам это контролировать, просто в таблице с описанием вьюшек и датасетов описать какое поле откуда берет перевод. При этом в мастер табличке поле с переводом держать имя в базовом языке.

3.В отдельной схеме, например, Lang хранить копии таблиц без атрибутов, только PK и поля которые могут быть с переводами во всех вариантах (F_Rus,F_Eng,F1_Rus,F1_Eng), а в мастер таблице вообще не хранить информации которая подлежит переводу. Можно дописать пакет который будет сам создавать все необходимые таблицы.

4. Совмещенный 2 и 3 вариант. В отдельной схеме таблички в которых

PK

Код языка

Filed_1

Field_2 ...

Ну и на последок еще и надо придумать универсальный интерфейс для всех модулей.
Ваши предложения и идее. Буду очень признателен.
...
Рейтинг: 0 / 0
06.07.2011, 18:37
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340459
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Я за первый вариант.
Что нибудь вроде переменной сессии, в зависимости от которой вычисляемое поле field (на которое смотрит gui) будет подставлятся из field_eng, field_rus. Правда надо будет подточить сохранение.
Новый язык - новый патч на базу. Действие понятное, осязаемое.

Второй хорошо подходит при бесконечном и постоянно растущем количестве языков и на мой взгляд не окупится.
...
Рейтинг: 0 / 0
07.07.2011, 08:45
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340551
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
SERG1257,

Но при 3 языках которые уже нужны довольно громадная таблица выходит, например в одной табличке есть 5 полей, 5*(3+основной) уже дополнительно 20 полей. С другой стороны намного проще так как нет проблем при построении вьюшек и заборников данных, да и в отчете легче дернуть поле от переменной языка.
Еще есть идеи или предложения?
...
Рейтинг: 0 / 0
07.07.2011, 10:02
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340576
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
"Прикрутить к работающему проекту" обычно означает довольно скромный бюджет. Поэтому с большой вероятностью я выбрал бы следующий вариант: в базе в "переводных" полях хранить что-нибудь типа <rus>Привет</rus><ukr>Здоровеньки булы</ukr><jew>שלום</jew>, а в приложении на уровне базовой формы/базового модуля вешать на dataset обработчик, скажем, AfterOpen, который отлавливает эти поля и вешает на них OnGetValue/OnSetValue, вытаскивающий/модифицирующий нужный язык. Плюсы решения:

1. Делается за пол-дня
2. Тривиально расширяется на любое количество языков
3. Язык легко переключается на ходу
4. Тривиально делается логика "если нет украинского перевода, используем русский"
5. Загрузка увеличивается только на траффик более длинных значений
...
Рейтинг: 0 / 0
07.07.2011, 10:12
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340581
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
softwarer,

В GUI понятно как отрабатывать, а как обрабатывать при построении View?
...
Рейтинг: 0 / 0
07.07.2011, 10:13
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340587
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
MorAdanВ GUI понятно как отрабатывать, а как обрабатывать при построении View?
А зачем там что-то обрабатывать? Какие есть view - пусть и работают. В них попадут такие композиты, и доберутся они до пользователя через тот же gui.
...
Рейтинг: 0 / 0
07.07.2011, 10:15
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340604
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
softwarer,

Ну это если все в GUI, а если строить отчеты например FastReport напрямую с вьшек то как то не очень понимаю как распарсить их.
...
Рейтинг: 0 / 0
07.07.2011, 10:23
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340635
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Если FastReport имеется в виду в приложении, то он точно так же опирается на dataset-ы. Да и собственные OnGetValue у него вроде бы есть. Если имеется в виду FastReport Server или как там его - не возился, не знаю. Возможно, таки придётся и в СУБД сделать функцию для парсинга таких многоязычных значений.
...
Рейтинг: 0 / 0
07.07.2011, 10:33
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340641
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Возможно, что-то типа варианта 2 нуждается в рассмотрении, т.е. када по имени схемы, имени табицы, имени атрибута и первичному ключу и коду языка можно узнать значение - (строка на соответсвующем языке) из соотвествующих таблов. Но пробовать вычислять это значение типа с помощью ф-ии, а не джойнами. Типа ф-я, которая по вышеуканным атрибутам в качестве праметров из соотвествующих табла буит находить значение.
...
Рейтинг: 0 / 0
07.07.2011, 10:35
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340659
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
vadiminfo,

В случае если реализовывать функцией то сильно возрастет нагрузка на БД. Для каждого столбца и строки будет вызваться функция в которой каждый раз будет select. Довольно дорогое удовольствие, учитывая что в онлайне более 100-200 человек постоянно что то делают.
...
Рейтинг: 0 / 0
07.07.2011, 10:40
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340781
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
MorAdan, ну да это физический аспект, который может иметь драмматическое значение. Но логический аспект (простота извлечения данных и возможности расширения в рамках рел таблиц) делает, его, возможно, нуждающимся в рассмотрении. Поскоку кажется наиболее простым при некоторых условиях. Например, искать компромисы в плане основной язык и переводы, в надежде что большинство на основном языке и там без ф-ий все. Какие-то способы расчитанные на физические аспекты. Я имел в виду не законченное решение а отправную точку для дальнейшего.
В общем случае вопрос стоит, насколько вообще подходят реляционные способы. И Логически и физичеки. Отказ от джойнов это уже отход от чистой реляционности. Возможно и дальнейший отказ. Например, какое-нить не совсем реляционное хранение, например не атомарное: для кажного атрибута сразу несколько значений на всех языках.
...
Рейтинг: 0 / 0
07.07.2011, 11:21
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340948
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
softwarer"Прикрутить к работающему проекту" обычно означает довольно скромный бюджет. Поэтому с большой вероятностью я выбрал бы следующий вариант: в базе в "переводных" полях хранить что-нибудь типа <rus>Привет</rus><ukr>Здоровеньки булы</ukr><jew>שלום</jew>, а в приложении на уровне базовой формы/базового модуля вешать на dataset обработчик, скажем, AfterOpen, который отлавливает эти поля и вешает на них OnGetValue/OnSetValue, вытаскивающий/модифицирующий нужный язык. Плюсы решения:

1. Делается за пол-дня
2. Тривиально расширяется на любое количество языков
3. Язык легко переключается на ходу
1. Да неужели !?
2. Как минимум придется увеличить длину строк. А если число языков будет расти, то надо постоянно удлинять.
3. А в отчетах ? Допустим это SQL-запрос из внешней программы. Это может быть и ОЛАР.

Удобно только для обслуживания морд внутри приложения. Именно так сделано в Навижн. Но сами данные в базе не локализуются.

ЗЫ: отдельное поле-идентификатор языка. Можно написать SQL-ф-ции извлечения нужного языка, типа GetTovarName(ID, LangID) и стараться извлекать через них. Тотальная переделка базы и процедур в БД.

Очень неблагодарная работа.
...
Рейтинг: 0 / 0
07.07.2011, 12:28
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37340954
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
LSV,

Согласен с вами, какой вариант предложите вы, интересно как это реализовано с ERP системах, например SAP?
...
Рейтинг: 0 / 0
07.07.2011, 12:31
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341045
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
LSV1. Да неужели !?
Вы про то, что не мешало бы добавить слова "компетентным разработчиком"? Согласен, они подразумеваются.

LSV2. Как минимум придется увеличить длину строк. А если число языков будет расти, то надо постоянно удлинять.
И в чём проблема?

Код: plaintext
1.
2.
3.
4.
5.
begin
  for cr in (select * from user_tab_columns where data_type = 'VARCHAR2') loop
    execute immediate 'alter table ' || cr.table_name || ' modify ' || cr.column_name || 'varchar2(' ||
      least ( 4000 ,  3  * cr.data_size) || ' char)';
  end loop;
end;

Вот не говорите, что на выполнение этого потребуется минимум месяц

LSV3. А в отчетах ? Допустим это SQL-запрос из внешней программы. Это может быть и ОЛАР.
Я могу придумать ещё прорву случаев, не входящих в постановку задачи.

Впрочем, я с удовольствием выслушаю Ваш вариант, и непременно спрошу, как он будет жить с ОЛАПом. Особенно меня будет интересовать выбор языка - что и как мне нажать в каком-нибудь стандартном олапе, том же Oracle BI, чтобы в отчётах волшебным образом сменился язык.

LSVУдобно только для обслуживания морд внутри приложения.
Ага. Что характерно, в постановке задачи именно это и требуется. Сначала возразим, потом прочитаем :)
...
Рейтинг: 0 / 0
07.07.2011, 13:01
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341186
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
softwarer,

Хм...
Думаю ваше решение можно сделать так:
1. Постоянно писать что то типа:
Код: plaintext
1.
2.
3.
Select Dm.Id_Material,
			 Pkg_Data_Lang(In_Source => Dm.Name, Id_Lang => Nvl(Sys_Context('Application', 'Current_Data_Language'),  0 )),
			 Dm.Is_Active
	From Dic_Materials Dm
2.Создать пакет для обработки в котором будет банальный SubStr.
3. Вьюшки сделать контекстно зависимыми
4. Учитывая что это Oracle 11 то можно сразу в табличку добавлять виртуально вычисляемые поля на основании базового поля.

Мину который я наблюдаю это ограниченная длина Varchar2(4000 байт, а для UTF8 это не 4000 символов), есть смысл смотреть в сторону BLOB.

Вы знаете ваше решение, на самом деле очень красивое, если использовать контексты то во вюшках надо банально его юзать, ну и в пакетах по созданию и обновлению записей добавить авто форматирование текста для необходимого языка.
...
Рейтинг: 0 / 0
07.07.2011, 13:47
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341272
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
softwarer"Прикрутить к работающему проекту" обычно означает довольно скромный бюджет.

А если финансирование нормальное, какой вариант Вы бы предпочли?
...
Рейтинг: 0 / 0
07.07.2011, 14:18
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341289
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
MorAdanПостоянно писать что то типа
Постоянно писать что-то типа - это ненадёжное и недешёвое решение. Я бы рассматривал такое в последнюю очередь.

MorAdanМину который я наблюдаю это ограниченная длина Varchar2(4000 байт, а для UTF8 это не 4000 символов),
Вряд ли это существенно. Как-то так выходит, что по бизнес-логике требуются либо достаточно короткие строки (скажем, до 100 символов), либо потенциально неограниченные портянки-memo, которые если и сделали varchar2(4000), то переclobить будет ничем не плохо.
...
Рейтинг: 0 / 0
07.07.2011, 14:24
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341298
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
softwarerMorAdanПостоянно писать что то типа
Постоянно писать что-то типа - это ненадёжное и недешёвое решение. Я бы рассматривал такое в последнюю очередь.


Ну если сделать один универсальный пакет, то можно постоянно использовать его функции и процедуры. Довольно постоянное решение, и если что то менять в логике, то оно и весь бизнес процесс затронет тоже. А контекстноя выборка с Nvl всегда будет гарантировать что если отсутствует перевод то будет использован язык по умолчанию.
...
Рейтинг: 0 / 0
07.07.2011, 14:27
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341441
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
MorAdanА если финансирование нормальное, какой вариант Вы бы предпочли?
Тогда как следует изучил бы реализацию проекта и требования к многоязычности и думал бы. Просто как один из возможных вариантов:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
conn data/data@db

create table _Currency (id integer primary key, code char( 3 ));

conn rus/rus@db

create table _Currency (id integer primary key references data.Currency(id), description varchar2( 4000 ));

create view Currency as select c1.id, c1.code, c2.description
from data._Currency c1, data._Currency c2
where c1.id = c2.id;

..........

conn user/user@db

alter session set current_schema = rus;

Впрочем, и изложенный не стал бы упускать из виду :)
...
Рейтинг: 0 / 0
07.07.2011, 15:21
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341451
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
softwarer,

Предыдущий мне как то больше нравиться, и легче с точки зрения докрутки к существующему, проблема в том что деньги есть времени нету :-). Пишется пакет который все это дело контролирует и потом проганяеться процедура на переделку всех необходимых полей и замену текста на маску.

Однако спасибо.
...
Рейтинг: 0 / 0
07.07.2011, 15:25
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341667
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
softwarerLSVУдобно только для обслуживания морд внутри приложения.
Ага. Что характерно, в постановке задачи именно это и требуется. Сначала возразим, потом прочитаем :)Да ну ? Задача как раз и стоит в локализации контента (!) и обсуждения структуры таблиц, т.е. ГУИ-морды и данных в БД.
Вся сложность именно в БД. Для ГУИ одно поле возможно самое оно.

Как в ОЛАПе разруливать строку, в кот. языки отделены самодельными текстовыми тегами ?

На самом деле весьма трудоемкая работа, если делать по уму, а не залипуху.
Серьезная переделка должна коснуться буквально всего и ГУИ и БД. Везде должен фигурировать желаемый параметр.

зы: предлагаю автору отказаться от этой затеи под любыми предлогами :) Это никто не оценит. Серьезно.

Про ERP-системы, в кот. есть готовая локализация данных (не подписей в ГУИ) не слышал. Встречал только банальных два поля. Но это залипуха.
...
Рейтинг: 0 / 0
07.07.2011, 16:37
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341687
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
LSV,

2 поля это полный фонарь. Насчет отказа тут еще подумать нужно, как ни крути а реализовывать нужно. Только надо определиться каким методом.
То что предлагает softwarer, на самом деле просто внедряется.
Опять таки все данные в софте вводятся через диалоги, они в свою очередь дергают процедуру из пакета, внутри GUI нету команд Insert или Update. Delete вообще отсутствует, все всегда храниться.
Что переделать необходимые справочники, GUI даже дергать не нужно, дописываются по 1-2 строке в каждой процедуре по работе с тем или иным справочником, + переделываются вюхи на котекстно зависимый вариант. По прикидкам моих людей за неделю можно реализовать, учитывая что справочников несколько сотен.
...
Рейтинг: 0 / 0
07.07.2011, 16:44
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341718
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
MorAdan,

Не зацикливайтесь на ГУИ. Что будете делать, когда понадобится внешние импорт/экспорт/ОЛАП, репортинг ?

Если у вас международная система (в разных странах), то возможно следует сделать просто некую прогу-шлюз для синхронизации разноязыковых данных. А прога в одном регионе пусть показывает только на одной языке.

Или Вам нужны данные для сайта ? Ну очень похоже.
...
Рейтинг: 0 / 0
07.07.2011, 16:54
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341740
MorAdan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MorAdan
Гость
LSV,

Данные не для сайта.
Система одна, интерфейс основной один, в нем и должна происходить смена языка. Делать еще две сотни таблиц под каждую не целесообразно, как на меня вариант хранить все в поле BLOB, а на базе виртуальных вычисляемых столбцов строить авто перевод на текущий язык. Тестируем еще пару вариантов, посмотрим на скорострельность. База как никак 3 терабайта.
...
Рейтинг: 0 / 0
07.07.2011, 17:02
| Ответить | Цитировать | Написать  
Ваши рекомендации по структуре мультиязичности данных БД
    #37341942
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
LSVДа ну ? Задача как раз и стоит в локализации контента (!)
Такой задачи не поставлено. Хотя обсуждаемая схема плавно решит её без каких-либо дополнительных работ. При запуске на "нелокализованных" данных будет выдаваться язык по умолчанию (то есть текущее содержимое поля), а редактирование приведёт к записи уже в форматированном виде обоих значений.

LSVи обсуждения структуры таблиц,
Видите ли в чём дело.... поставленная задача - это не "доработать таблицы, дописать код". Так ставят задачу кодировщикам, и наружу такие постановки не выходят. Поставленная задача в данном случае - прикрутить мультиязычность к работающему Oracle/Delphi/GUI проекту.

LSVКак в ОЛАПе разруливать строку, в кот. языки отделены самодельными текстовыми тегами ?
Вы вообще с ОЛАП когда-нибудь сталкивались? Слово "разруливать" вызывает глубокий вопрос, что Вы имеете в виду, но на всякий случай подскажу: ОЛАПу строки вообще в 100% случаев пофиг, ему не нужны никакие операции с ними, и участвуют они только как надписи на осях.

Также напомню вопрос, который Вы стыдливо заминаете: а где в постановке задачи этот пресловутый ОЛАП? Сами придумали, вместе со всем прочим, что несёте?

LSVНа самом деле весьма трудоемкая работа, если делать по уму, а не залипуху.
Серьезная переделка должна коснуться буквально всего и ГУИ и БД. Везде должен фигурировать желаемый параметр.
Вам бы, батенька, в продавцы пойти, раскручивать лохов на "трудоёмкие работы" вместо того, что им нужно.
...
Рейтинг: 0 / 0
07.07.2011, 18:33
| Ответить | Цитировать | Написать  
25 сообщений из 28, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ваши рекомендации по структуре мультиязичности данных БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=37341451&tid=1542094]:
 0ms
get settings:
 6ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 302ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 46ms
get tp. blocked users:
 1ms
others: 205ms
total:  594ms
созд. / загр.: 594ms
x
x
Закрыть


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