Здравствуйте.

В базе необходимо хранить наименования различных вещей на разных языках. Например, людей (фамилия и имя). Количество используемых языков не хочется заранее ограничивать, хотя первоначально будут только русский и английский.

Для любого человека будут поля, задающие его имя и фамилию на любом языке, но заполнены могут быть не все из них. Языки будут как-то упорядочены.

Хотелось бы, чтоб при запросе фамилии и имени человека с указанием языка выводились фамилия и имя на этом языке. А если на требуемом языке нет данных, то перебирались бы другие языки в том порядке, как они упорядочены и выводились на первом языке, на котором они есть. И если только ни на одном языке не указаны фамилия и имя, то тогда выводить пустые значения.

Это то, чего хочется по максимуму. Хотя скорее всего можно будет гарантировать, что на английском языке всегда будут заполненные данные.

Возможно ли это сделать средствами дизайна или нужно будет писать дополнительный программный код?

Дизайном я называю проектирование базы, например, в ORACLE SQL Developer Data Modeler. Соответственно он может создать DDL-скрипт (и не только) для создания таблиц и связей между ними для различных баз (для Оракла, MSSQL и др.).

Сервак соответственно может быть разный, предположим Oracle 10.2.

mcureenabСтруктура БД не решает такие задачи без "дополнительный программный код". Учту Ваше мнение.

mcureenabА код видимо такой.
... Это всё понятно, спасибо.

GUESTпричем это тривиальное задание изложено как невнятный бред

имена и фамилии на языки вообще не переводятся ... Где Вы увидели требование переводить имена и фамилии? Сами себе придумали бред ...

spНу кроме как резервирования полей под каждый язык не обойтись - кто же за вас напишет ФИО Васи Пупкина на всех языках и когда - наверняка при вводе и сразу на всех языках - иначе навряд ли кто-то это сделает потом Было изначально указаноавторДля любого человека будут поля, задающие его имя и фамилию на любом языке. В принципе я вижу 2 пути:

1. Хранить написание на всех языках в одной записи, в разных полях.
2. Хранить в разных записях и дополнительно иметь поле для языка.

Так как я указал, что заранее количество языков (и соответственно тем более их список) нежелательно ограничивать, то первый способ сопряжён с реорганизациями базы при добавлении каждого нового языка. Чего, конечно, хотелось бы избежать.

Сразу на всех языках невозможно (да и не нужно) заводить. Предполагается, что на на своих национальных языках данные будут заводить люди, владеющие этими языками (знающие как пишутся имя и фамилия). По возможности хотелось бы, чтоб они сразу заводили и на английском (и вообще на всех языках, каких смогут), но для работоспособности системы это не обязательно. Кстати это ещё не вся проблема. На разных языках идентифицирующие человека данные могут отличаться. На английском не принято указывать отчество. У испанцев обычно несколько имён, у корейцев по три слова, но они вроде бы не вполне соотносятся с нашими именем, фамилией и отчеством, и т.д.. Помимо имён людей нужно хранить и другую информацию на разных языках.

Я сам склоняюсь к мнению mcureenab`а - что эту задачу в изначальной постановке решить невозможно, но обоснования у меня нет.

_хех
за п.1 убить надо
...
учись лучше запросы писатьВот в чём смысл таких "советов"? Вы думаете, что показали свою крутость? Пока Вы показали только своё хамство и невоспитанность. И больше ничего. Какой программный код писать - вполне доступно изложил mcureenab.

mcureenabИМХО, вместо написания ФИО на всех возмжных языках проще писать ФИО на оригинальном языке, и по возможности на английском (всё таки международный). А для поиска использовать фонетический ключ (транскрипцию), потому как обычно принято людей звать так как они звучат на родине, хотя бывают и исключения.

Тот же самый Чингачгук Большой Змей (CHINGACHGOOK, DIE GROSSE SCHLANGE). Для русских "DIE GROSSE SCHLANGE" теряет смысл.

Ещё есть практика - для неформального общения иностранцы с труднопроизносимыми именами берут себе местные псевдонимы.Я может быть не совсем удачно составил первоначальное описание. Меня скорее интересуют именно возможности СУРБД по решению такого типа задач. Можно считать задачу более абстрактной, а имена, фамилии, языки взяты для примера (но мне действительно желательно реализовать хранение и обработку на различных языках). Хотя, конечно, поиск по фамилии тоже планируется, однако я расчитывал искать только с указанием языка. Думаю, что нет смысла делать поиск на языках кроме английского и родного для искомого человека. И английский тут только потому выделен, что он предполагается самым заполненым - в идеале у каждого человека должен быть указан.

Ну и сам вопрос-то у меня был не о поиске. Я попытался в `Oracle SQL Developer Data Modeler`е набросать схему со связями и у меня не получилось нормально всё замкнуть. Наверно придётся для начала вообще не заморачиваться языками и оставить только английский. Хотелось решить эту задачу красиво, но, похоже, не удастся.

guest_20040621> Хотелось решить эту задачу красиво

Раз пятьсот здесь обсуждалось, ищите внимательнее.Я нерегулярно читаю этот форум. Попробую поискать, но не могли бы Вы привести пример хотя бы одного постинга по этой теме?
kinkМожно ещё добавить поле Priority либо в Names, либо в Languages, в зависимости от задачи.Когда я писал, что языки будут упорядочены, я примерно это и имел ввиду, но я не понимаю как это поможет соединить таблицы в Data Modeler`е.

И я ещё раз повторяю, что ничего фонетически переводить не надо. Кроме фамилий и имён планируется хранение географических названий (города, страны) и небольшое количество специальных терминов. Предполагается, что на национальных языках эти слова будут заводить люди, точно знающие, как они пишутся. А все навороты с подстановками придуманы, чтоб отобразить не пустые поля, а хоть что-нибудь, если оно есть на каком-нибудь другом языке. Часть слов может быть и не нужно переводить. Например, если заведен город Москва на русском языке, то зачем его заводить на украинском? Всё равно пишется также. Если Berlin заведён на немецком, зачем его заводить на английском? И т.д.

mcureenabНу... Возможно кодировка символов будет другая. Ведь в юникоде не всегда обращают внимания на одинаковое начертание букв или иероглифов.

Отличи русскую эс и английскую си:
Я специально привёл пример, где буквы те же самые и в юникоде.

Пекин - Beijing - 北京
Про Пекин никто и не говорит. Но, кстати, известно, что японцы пишут китайскими иероглифами. Поэтому Пекин (а также вероятно и все остальные китайские географические названия) пишется по-японски также как и по-китайски. Насколько точно у них там это соответствует я не знаю. Но я знаю, что японцы скорее всего поймут китайские иероглифы даже если на японском языке что-то пишется не так или не в той кодировке. И это уже хорошо.
Если не заводить, придётся писать код, который будет разбираться почему не завели и можно ли использовать вместо английского другой текст.

На уровне структуры данных придётся текстовые описания вынести в отдельную таблицу. Для каждого языка - отдельная запись.

Для поиска в этой таблице в SQL можно использовать операторы контекстного поиска, которые возвращают число - релевантность записи заданному запросу и возвращать запись с наилучшим значением релевантности, которое вчастности может зависеть от языковых предпочтений пользователя. Можно поподробнее про операторы контекстного поиска? Что это такое, где реализовано? Пока правда это не самая актуальная задача, но в будущем может пригодится.
Основная цель всей этой мороки с языками - дать возможность людям, которые не знают, как их родные имена, фамилии и города пишутся на английском языке, всё-таки заполнить информацию и иметь возможность при запросе на своём языке её получить. А заполнением на других языках могут впоследствии заняться более сведующие товарищи.