powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Организация БД мультиязычного сайта
25 сообщений из 60, страница 2 из 3
Организация БД мультиязычного сайта
    #38431883
Фотография lLocust
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roman_lenkoГхостик, извиняюсь, но я не понимаю вашего примера. Тут уже «переводы» пошли, «тексты» — помоему, это из другой области, или я вы предлагаете принципиально другую реализацию.

То же самое, что и предложил Кот Матроскин просто:
1) в других терминах
2) с дополнительной таблицей для определения типов сущностей
3) Более удобный с точки зрения дальнейшего сопровождения кода (другой программист сразу поймет как это все работает)
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432012
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> create table dbo.City()
> create table dbo.Literal()

Всё бы хорошо, Кот Матроскин, но вам понадобятся эквиваленты не только названий, но и топонимов. Иногда прямое соответствие для разных языков существует, иногда нет. Что намерены делать?
Не совсем понял фразу "не только названий, но и топонимов". Можете привести пример?
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432021
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Можете привести пример?

Город, село, деревня, станица, рабочий посёлок, хутор и пр. Уровень выше (не топонимы, но сходная задача): край, область и пр.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432054
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roman_lenkoSgt.Pepper, я немного подредактировал то, что вы написали: я добавил FOREIGN KEY для dbo.Literal.id_city — это правильно?Разумеется. Я FK не описал, думал - само собой понятно...
roman_lenkoЯ вот теперь не понимаю зачем мне нужно ID написания, если у меня, например, уже есть languageId?С точки зрения строгой теории - не нужен, в качестве PK вполне может выступить id_city+id_language. Просто для меня правило - для каждой таблицы создавать суррогатный ключ...

Лучше расскажите как предполагается работать с этими multilanguage-городами.
У Вас есть что-то типа КЛАДР для разных стран на разных языках?
Или Вы предполагаете иметь специалистов, которые для тысяч, скажем, российских городов будут вводить эквивалент на суахили?..
Проблема ли то, что некий город для выбранного языка не имеет в базе "перевода" и, как следствие, для пользователей, выбравших этот язык, не отобразится?
Т.е., другими словами, для каждого языка будет свой набор городов...
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432083
roman_lenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ребят, спасибо — столько ответов, прямо не ожидал.

lLocust А вам и не нужно ID написания, смело удаляйте. А primary key составной на id_city и languageId.

Блин... и постарайтесь придерживаться единых правил: или id_city и id_language или cityId и languageId. Сами же потом путаться будете )

P.s. и еще Кот Матроскин предлагал сделать одну таблицу для всех переводов (поэтому добавил поле ObjectTypeID - обозначающее что за перевод тут хранится). Вы это поле убрали и фактически сделали эту таблицу только для перевода городов. Вот и назовите ее как-нибудь CityTranslate, а не Literal (а то потом другому разработчику будет сложно понять что вы хотели).


Простите-с, а как составной Primary Key определять? — разве кластеризированный индекс можно объявлять для более чем одного поля таблицы (я использую Microsoft SQL Server).

Про написание — то понятно; автор так написал — я и скопировал.

И наконец-то понял, что это за Literal такой! Я же не знал, что по задумке Матроскина это одна таблица для всех переводов. Нет — мне только для городов нужно.

Sgt.PepperРазумеется. Я FK не описал, думал - само собой понятно...

Ну... нет :) Какраз такие детали для меня и составляют «паззл» целиком — лучше дважды переспросить.

Sgt.PepperЛучше расскажите как предполагается работать с этими multilanguage-городами.
У Вас есть что-то типа КЛАДР для разных стран на разных языках?
Или Вы предполагаете иметь специалистов, которые для тысяч, скажем, российских городов будут вводить эквивалент на суахили?..

Да нет — всё намного проще. У меня уже есть готовый проект — сайт поиска музыкантов . Но он пока только на русском языке, а я хочу перевести его на другие языки, т.к., он сейчас для 3-х стран действует: Украина, Россия, Беларусь. Вот, например, есть объявление о поиске музыканта , в нём человек, при регистрации, выбрал себе город «киев, украина» (сущность «город», City ) и инструмент «гитара/электрогитара» (сущность «инструмент», Tool ), так вот я хочу, чтобы, например, в украинской версии сайта у музыканта было написано «київ, україна» и «гітара/электрогітара» соответственно — для этого вся эта канитель с городами и началась — мне нужно перевести все доступные в базе данных города на другие языки, чтобы они показывались на странице музыканта. Идея такова.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432099
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roman_lenko,

Вы только незабывайте что имена собственные непереводятся.
Ну и "электрогітара" - нет такого слова в украинском.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432108
roman_lenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Злой Бобрroman_lenko,
Вы только незабывайте что имена собственные непереводятся.
Ну и "электрогітара" - нет такого слова в украинском.

Ну, города ведь пишутся по разному, например, киев = київ. Да — гитару неправильно написал — електрогітара.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432113
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roman_lenko,

Не все города. Поэтому и предупредил, т.к. сам наступал на эти грабли во времена "студенчества".
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432122
roman_lenko
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Буду иметь ввиду — спасибо. Все равно буду в Википедию подсматривать — там точно не ошибусь.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432202
Гхостик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
roman_lenkoодна таблица для всех переводов. Нет — мне только для городов нужно.



roman_lenkoв украинской версии сайта у музыканта было написано «київ, україна» и «гітара/электрогітара» соответственно

Вижу несоответствие.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432435
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Можете привести пример?

Город, село, деревня, станица, рабочий посёлок, хутор и пр. Уровень выше (не топонимы, но сходная задача): край, область и пр.
Не представляю себе задачу, чтобы точная работа с этим была важна при переводах . Ну назовут при переводе и деревню и село village - какая разница? Даже если окажется, что мы два разных обьекта "село Ивантеевка" и "деревня Ивантеевка" назвали одинаково Ivanteevka village - ну и черт бы с ним, мы же не почтовые адреса печатаем.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432478
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин,
Есть ли необходимость в существовании наименования города в City?
Что там должно стоять для Киева, Москвы и Рима, учитывая что русские, украинские и итальянские названия всех трех городов есть в Literal?..
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432489
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sgt.PepperЕсть ли необходимость в существовании наименования города в City?

Есть, Default Value. Ведь соответствующей записи в Literal может не быть, тогда можно IsNull(Literal.Name, City.Name)
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432491
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sgt.PepperЕсть ли необходимость в существовании наименования города в City
В приведенной мной схеме - нет, конечно.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432506
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Не представляю себе задачу, чтобы точная работа с этим была важна

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

> какая разница?

Неправильно идентифицированный населённый пункт = неправильно решённая задача. Источников геморроя два: топонимы и правила перевода. Даже однозначных общепринятых правил транслитерации не существует, не говоря о прочем.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432719
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arm79Есть, Default Value. Ведь соответствующей записи в Literal может не быть, тогда можно IsNull(Literal.Name, City.Name)И что будет для Рима default value?
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432760
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot guest_20040621
Неправильно идентифицированный населённый пункт = неправильно решённая задача.
...
Даже однозначных общепринятых правил транслитерации не существует, не говоря о прочем.[/quot]
Совершенно верно. Поэтому пытаться что-то однозначно идентифицировать по переводу - имхо совершенно безнадежное дело. Насколько я знаю, если написать на конверте по русски " Великобритания, Лондон, Бейкер-стрит 221B" - письмо не дойдет
никуда по определению.
Топонимы имхо важны для другого - понимать, что для обозначения столицы РФ "город Москва", "г Москва" и "г. Москва" - это правильное написание, а "с. Москва" - какая-то фигня.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432842
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> идентифицировать по переводу - имхо совершенно безнадежное дело

Не уверен. Но это не совсем перевод, это эквивалент (топоним + название) с кучей правил и исключений.

> Топонимы имхо важны для другого

Почему бы вдруг селу не стать столицей? По мне, Москва и есть большая деревня.

Топонимы могут нести семантическую нагрузку, которую глупо терять. ОК, не важно, в конце концов, для чего их можно использовать. Не хотите модифицировать предложенный вами вариант?
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432924
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Топонимы могут нести семантическую нагрузку, которую глупо терять. ОК, не важно, в конце концов, для чего их можно использовать. Не хотите модифицировать предложенный вами вариант?
Мне не до конца понятна задача - что мы хотим от структуры?

Ну например, добавить таблицу "Типы населенных пунктов" (соответственно, в City внешний ключ на нее), вбить в нее все национальные деления (т.е. там будут, в частности, 3 разные записи "Село", "Деревня", "Village"), иметь в этой таблице поле "Страна, в которой принято данное деление" (внешний ключ на таблицу стран), в моей таблице Literal хранить переводы типов точно также как переводы городов.
Т.е. для типа "Деревня" будут записи в Literal
RU Деревня EN Village
для "Село"
RU Село EN Village
для "Village"
EN Village RU Деревня

Такую структуру переводов несложно дозаполнить автоматически, при этом оставив у эксперта-человека возможность вмешаться и поменять данные так, как он считает нужным.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432979
Arm79
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sgt.PepperArm79Есть, Default Value. Ведь соответствующей записи в Literal может не быть, тогда можно IsNull(Literal.Name, City.Name)И что будет для Рима default value?

Какой язык первичный, такой и писать. Если сайт ориентирован в первую очередь на Запад, то английский
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38432999
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> что мы хотим от структуры?

Вариант, который устроит нас в неизменном виде для 99% случаев. Т. е. почтовая адресация, картография, логистика и пр. в него должны уложиться.

> добавить таблицу "Типы населенных пунктов"

Категоризацию можно использовать, но контекстно-зависимого деления я бы избегал по многим причинам.

> для типа "Деревня" будут записи в Literal

Не смущает, что у вас разные результаты для разных направлений преобразования?
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38433295
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> для типа "Деревня" будут записи в Literal

Не смущает, что у вас разные результаты для разных направлений преобразования?

Совершенно нет.
1. Направление преобразования всегда одно - перевод с родного по отношению к топониму языка на иностранный. Я уже говорил,
что считаю задачу автоматического перевода "город Лондон" на английский и на основании перевода идентификации города - неразумной.
2. Даже если отвлечься от 1., для переводов это вообще нормальная ситуация. Если Гугл транслейтом перевести текст с русского на английский и потом обратно на русский - результат тоже будет отличаться от первоначального.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38433369
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Если Гугл транслейтом перевести текст

Мы обсуждаем имена собственные, и как раз с ними у google есть проблемы. ОК, давайте на этом закончим. Спасибо за изложение вашей точки зрения.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38433423
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roman_lenko таблица dbo.User одна в неизменном виде, а вот таблиц dbo.City должно быть несколько: одна версия с русскими названиями городов, вторая, пускай, с английскими названиями тех же городов с теми же идентификаторами. Это нужно для того, чтобы можно было извлекать данные пользователя как с русскими названиями городов, так и с английскими. ПРИЧЁМ, dbo.City на русском будет находится в одной базе данных, а dbo.City на английском — в другой базе данных; при этом dbo.User должна быть общей для обоих баз данных — как это реализовать?

1) Самый брутальный вариант — держать 2 копии таблицы dbo.User в обоих базах данных, но таким образом мне необходимо будет данные в 2-х таблицах синхронизировать, а это значит нужно писать систему синхронизации, чего делать мне не хочется.

2) Второй вариант, держать в базе данных 2 таблицы городов: dbo.CityRUS и dbo.CityENG и уже, в зависимости, например от какого-то передаваемого в запрос параметра с идентификатором языка, выполнять переключение в дуже SWITCH:

Код: c#
1.
2.
3.
4.
5.
6.
7.
SWITCH langId:
    case "RUS":
      select ... join on dbo.CityRUS.id;
      break;
    case "ENG"
      select ... join on dbo.CityENG.id;
      break;



Но, я считаю, что это извращение.


Правильно считаешь.
Никаких двух баз, никаких двух таблиц быть не должно.


автор3) Вариант — сделать так, чтобы в таблице городов хранились и русские и английские названия в разных колонках — не вариант, потому, что БД желательно разместить на разных серваках — из-за неоднородности нагрузки исходящей от клиентов, которые используют английские и русские названия городов.


Ты прав, не вариант.

Решается достаточно просто , в общем, есть два варианта.

Либо к каждой таблице, где храняться переводимые данные, ты делаешь таблицу с суффиксом (или префиксом) , например, "_INT"
или "_TRANS", где таблица состоит из:

полей PK изначальной таблицы

добавленного в PK идентификатора языка (лучше в виде текстовой константы -- кода языка типа 'RU' 'EN' и т.д.)

в неключевые атрибуты идут все атрибуты из основной таблицы, которые требуют перевод, с теми же типами данных.

Таким образом, у тебя получается таблица один-ко-многим с основной, в которой хранятся переводы данных основной таблицы на разные языки.

Использование очевидно:

Код: sql
1.
2.
3.
4.
select 
  c.city_id, coalesce( ct.name, c.name ) as name
from CITY c
left join CITY_TRANS ct on c.city_id = ct.city_id and ct.lang = 'RU'




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

PK -- ид сущности, ид атрибута сущности, ид экземпляра сущности, ид языка. Атрибут один -- значение атрибута на данном языке.

Запросы аналогичны, только ещё константами будут задаваться ид сущности и ид атрибута сущности.
...
Рейтинг: 0 / 0
Организация БД мультиязычного сайта
    #38433424
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
roman_lenkoНо, я считаю, что это извращение.


Роман, кстати хочу отметить особо, что очень здорово , что у тебя сразу возникло такое чувство.
Это значит, у тебя есть правильное реляционное мышление, ну или хотя бы его задатки.
...
Рейтинг: 0 / 0
25 сообщений из 60, страница 2 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Организация БД мультиязычного сайта
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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