| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > Локализация данных в БД |
| Автор: dimqw31 29.10.2010, 12:54 |
| Допустим у меня приложение разрабатывается для трех языков Как лучше организовать БД для лучшей гибкости, производительности при запросах.. В одной таблице иметь несколько колонок с разными переводами элементов данных или для каждого языка сделать свою БД? Или другие какие есть способы или паттерны, |
| Автор: Frees 29.10.2010, 13:02 | ||
точно нет! в таблице иметь несколько записей одного и того же текста на разных языках ID |LANG_ID |DATA 1 1 Черновик 1 2 Draft 2 1 Завершен 2 2 Complete LANG_ID |LANG 1 Ру 2 En или иметь набор скриптов с UPDATE который будет изменять данные на другой язык для каждого языка свой скрипт |
| Автор: Akella 7.11.2010, 20:50 |
| Может иметь три набора одинаковых таблиц? А потом представлениями или процедурами выбирать нужные данные? В процедуру можно передавать как параметр код языка. |
| Автор: _Y_ 8.11.2010, 14:38 | ||
Если каждое слово/фраза должно присутствовать в переводе на все языки, то вполне подойдет таблица с отдельной колонкой на каждый язык:
Я так делал длал для несколькоязычных вебсайтов. В этом случае поиск чрезвычайно прост, но в программе приходится жестко прописывать соотношение язык - колонка таблицы. Если же переводы между языками случайны или, например, языки это тоже объект хранения БД (например языки можно добавлять и удалять), то делать надо как сказал Frees |
| Автор: Akella 13.11.2010, 12:42 |
_Y_, в твоём случае нужно будет постоянно строить запросы динамически. Т.е. жёстко в наборе данных не пропишешь запрос, как это часто мы делаем. Да и в моём случае тоже. Наверное самый лучший вариант будет тот, который предложил уважаемый Frees  |
| Автор: Frees 13.11.2010, 14:10 | ||
там тоже проблем не мало например с первичными ключами, усложнение запросов (потенциальные ошибки). или Вы про второй вариант - скрипт переводящий БД... я бы скриптом сделал. |
| Автор: Zloxa 13.11.2010, 21:51 |
| А вообще.... языковые настройки презентационного слоя хранить в персистентных данных.... Это только для меня нелепо звучит? |
| Автор: Akella 13.11.2010, 21:58 | ||||||||
Ну легче ж просто передать значение значение нужного языка в параметр
Добавлено через 1 минуту и 30 секунд Вообще можно в каком-нибудь событии у компонента подключения к базе определять запрос или датасет и автоматически добавлять условие where lang_id = :lang Добавлено через 2 минуты и 37 секунд
где, где? можно по-русски? без "американщины", так сказать  Мы ж славяне!!!! а не американцы  |
| Автор: Frees 13.11.2010, 22:06 | ||||
первичный ключ составной надо будет делать...
Для меня это звучит непонятно..)) |
| Автор: Zloxa 13.11.2010, 22:10 | ||
Я очень долго думал над тем, как это сказать по русски, прежде чем сдался и использовал этот американизм :( |
| Автор: Frees 13.11.2010, 22:11 | ||
можно для таких переводимых таблиц сделать view которая сама будет это условие языка (lang_id = :lang) учитывать а текущий lang_id хранить отдельно где то в БД в некой таблице настроек (это помоему и есть "настройки презентационного слоя хранить в персистентных данных") |
| Автор: Zloxa 14.11.2010, 03:17 | ||
Не, я не то имел в виду. Хотя это тоже оно Я малость подзагнался, спроецировал свою задачу, хотя не факт что она имеет место быть у ТС. На неделе ковырял локализацию ORMS. Они лаблы форм, значения листов, комбо и пр. слили в базу и, при инициализации формы, в зависимости от языка пользователя, подтягивали нужные. Мне показалось это не совсем кошерным. Совсем не кошерным. Тот самый случай, когда настройка(конфигурация) ГУЯ слита в базу. Мне кажется это не лучшая практика. Я понимаю что это все от бедности, и пытаюсь приучить себя к мысле что это нормально. Но пока у меня получается плохо. Хранить в базе конфиг гуя, мне видится абсурдным. Слой данных должен быть абстрагирован от презентативного слоя. ИМХО. В смысле что не важно на чем у нас клиент. На формсах, пыхапы, жаве, делфе, или же вообще нет- на структуру и состав данных это влиять не должно и баста. Твое предложение с вьюхой сродни этому. Я не отрицаю практического удобства такого подхода. Напротив. Это очень удобно. Однако же с точки зрения "философии" визуализация это исключительно задача клиента, а корректное отображения языка это задача визуализации. |
| Автор: Frees 14.11.2010, 22:18 |
| Я думаю, надо разделять 2 уровня локализации: 1 - локализация текстов у Label на формах клиента; 2 - локализация названий сущностей БД или их атрибутов. первое хранить в БД это противоречит "философии" а второе очень даже не противоречит Но проще реализовать один общий механизм, поэтому тексты Label и попадают в БД. |
| Автор: Zloxa 15.11.2010, 11:03 | ||
В том то и проблема, что, если с первым, описанным тобой случаем, я имею дело весьма регулярно, то со вторым - еще ни разу не доводилось сталкивался, хотя таки допускаю что подобные задачи имеют место быть. Именно узость моего кругозора и мешает мне допустить что проблема описанная ТС действительно должна решаться средствами БД. |
| Автор: Akella 21.11.2010, 16:38 |
| А если на момент запуска программы не будет подключения к базе (сбой и т.д.), то что тогда? Все сообщения об ошибках и окна программы будут как выглядеть? |
| Автор: former 22.11.2010, 14:59 |
| А почему бы локализации не запихнуть в xml и хранить в базе? |
