|
|
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
Hi All! Есть вот такая табличка, которая используется для хранения локализации выпадающих списков. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Которая заполнена, например, такими данными. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Данные из нее обычно извлекаются запросом вида Код: sql 1. Все это вполне нормально работает, но иногда при большом количестве различных локализаций или просто из-за ошибки в какой-нибудь из локализаций, например, в en_us в моем примере, не все возможные значения для value присутствуют (нет для 003). Нужно написать такой запрос, чтобы всегда возвращался все возможные уникальные значения для value по заданному name. Если же какой-то пары value => text для запрашиваемой локали нет, то должно подставляться из другой. Возможные варианты подстановки (в порядке возрастания желания): Если для запрашиваемой локали нет, то берется первое попавшееся из другой локали (наименее предпочитаемый) Если для запрашиваемой локали нет, то берется из локали по умолчанию, а если и там нет, то первое попавшееся из другой локали Если для запрашиваемой локали нет, то берется из локалей в порядке убывания приоритетов, а если и там нет, то первое попавшееся из другой локали (самый лучший вариант). Например, для локали en_us при умолчательной ru_ru будет список - 002 => Second, 001 => First, 003 => Третий (порядок сортировки тоже нужно учитывать). Как лучше составить запрос, чтобы реализовать описанные выше требования и при этом получить максимальную производительность? Какие индексы и при необходимости дополнительные поля стоит добавить? Порядок приоритетов локалей может меняться, т.ч. он должен быть описан в запросе. Решения с хранимыми процедурами или функциями не подходят, т.к. в этом случаем мне проще реализовать все это на прикладном уровне в приложении. Решение должно быть либо универсальным (не зависеть от СУБД), либо иметь реализацию для MySQL и MSSQL. Заранее всем спасибо за помощь!!! Дмитрий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 12:20 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
HiDivВозможные варианты подстановки (в порядке возрастания желания): Если для запрашиваемой локали нет, то берется первое попавшееся из другой локали (наименее предпочитаемый) Если для запрашиваемой локали нет, то берется из локали по умолчанию, а если и там нет, то первое попавшееся из другой локали Если для запрашиваемой локали нет, то берется из локалей в порядке убывания приоритетов, а если и там нет, то первое попавшееся из другой локали (самый лучший вариант). для начала сами определитесь чего хотите и как должно быть правильно - телепатов нету какие у вас потребности на самом деле. Вы описали самую верхушку айсберга. В чем проблем сделать любой из предложенных вами вариантов? если про оракл говорить - есть такая функция decode. Кроме того есть конструкция Case when... В других базах наверное тоже что то аналогичное есть. На счет всех типов баз, чтобы один запрос работал не уверен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 13:08 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
Sergueiдля начала сами определитесь чего хотите и как должно быть правильно - телепатов нету какие у вас потребности на самом деле. По моему я весьма конкретно описал проблему. Еще раз повторю если запутал, нужно возвращать список для всех уникальных value в порядке убывания приоритетов локалей. Высшая по приоритету запрашиваемая локаль, далее может быть одна или несколько других локалей в порядке убывания приоритетов и наконец любой вариант из оставшихся локалей. SergueiВы описали самую верхушку айсберга. Не совсем понял про "айсберг", что еще мне нужно описать? SergueiВ чем проблем сделать любой из предложенных вами вариантов? В том, что у меня не получилось описать самому такой запрос (во всяком случае оптимально) и прошу помощи у сообщества... Sergueiесли про оракл говорить - есть такая функция decode. Кроме того есть конструкция Case when... В других базах наверное тоже что то аналогичное есть. На счет всех типов баз, чтобы один запрос работал не уверен. Я указал в посте какие СУБД меня интересуют если нельзя сделать универсальный, Oracle в этом списке нет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 13:34 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
HiDivЯ указал в посте какие СУБД меня интересуют если нельзя сделать универсальный, Oracle в этом списке нет... 1) Ну вы и лентяй батенька. Даже не хватило сил посмотреть- а в ms sql такие функции есть. 2) Кроме того, если хотите помощи в написании запроса потрудитесь предоставить исходные данные для тестирования- то что вы привели в первом посте, врядли у кого-то возникнет желание создавать ваши таблицы. Что то типа Код: sql 1. 2. 3. 4. 5. 3) если вопрос по специфике конкретной базы- задавайте вопрос в соответствущем разделе форума ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 13:48 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
HiDivчто еще мне нужно описать? Например, с какого перепою строка может отсутствовать в базовой локали. Или назачем кому-то может понадобиться строка из случайной локали. Выставь требование заполнителю данных, что в базовой локали строка отсутствовать не может, и запрос сведётся к тривиальному left join + coalesce(). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 13:48 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
скалярный подзапрос типа для MSSQL Код: sql 1. 2. 3. для MySQL копай в сторону limit или спроси более компенентных товарищей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 16:20 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovНапример, с какого перепою строка может отсутствовать в базовой локали. Или назачем кому-то может понадобиться строка из случайной локали. Ну, например, базовая локаль может в системе меняться и очень динамически. Данный справочник ведут не админимы, а скажем продвинутые пользователи. Соответственно при необходимости добавить новое значение списка этот пользователь добавляет его только в своей родной локали, т.к. не знает и не хочет знать о существовании других. Добавленное значение value сразу может быть указано, как значение полей в других таблицах (это ведь просто справочник с функциями локализации). Соответственно из-за отсутствии "родной" локализации другой пользователь (с совсем другой локалью) должен сразу увидеть новое значение пусть и на таробарском языке. А вот уже после этого он или совсем другие люди могу добавить все необходимые локали (или оставить как есть). У меня получилась вот такой запрос Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Насколько он оптимален (это MySQL)? Какие индексы стоит добавить или что-то еще поменять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 18:15 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
HiDivиз-за отсутствии "родной" локализации другой пользователь (с совсем другой локалью) должен сразу увидеть новое значение пусть и на таробарском языке А что бы лично скажешь, увидев посередине русского списка китайские иероглифы и что-то на португальском? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2015, 18:57 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovА что бы лично скажешь, увидев посередине русского списка китайские иероглифы и что-то на португальском? Вам не кажется, что это уже разговор не о чем! Задачу я уже довольно подробно описал и на вопросы "зачем" и "почему" ответил... Что же касательно Вашего комментария, то как минимум он увидит, что значение поля заполнено, а не пустое. А если войдет в режим редактирования записи (разговор про веб-интерфейс), то выпадающий список (options для select) будет содержать "правильное значение" пусть и на китайском и не перепишется на пустое или первое в списке при попытке сохранения записи без каких-либо изменений данного поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 09:54 |
|
||
|
Работа с таблицей для хранения локализации
|
|||
|---|---|---|---|
|
#18+
HiDivвыпадающий список (options для select) будет содержать "правильное значение" пусть и на китайском и не перепишется на пустое или первое в списке при попытке сохранения записи без каких-либо изменений данного поля. Чо? Как ты добился такого дикого поведения? А, нет, не говори, дай угадаю: посылаешь в базу тупой номер пункта в списке по порядку, без учёта его содержимого. В морг. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2015, 12:20 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=39082805&tid=1540458]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
147ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 247ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...