Сохранение текстов на разных языках в базе данных
какую на самом деле задачу решаете.
Есть/проектируется какая то база данных, ну например, поставщики товаров с адресами и товарами.
Таблиц и связей достаточно, уж точно больше десяти.
База заполняется, допустим на немецком. Но есть хотелка, что бы информация записанная в базе была доступна еще и на других языках.
Интересно обсудить варианты решения, найти + и -.
Примерно так. Только связь между городом (улицей) и таблицей связей 1-*.
Или, если я правильно понимаю, если в таблице связей ключ будет составной (из двух айдишников - города и языка, например), то связь между городом и таблицей связей можно сделать 1-1?
Есть/проектируется какая то база данных, ну например, поставщики товаров с адресами и товарами.
Таблиц и связей достаточно, уж точно больше десяти.
База заполняется, допустим на немецком. Но есть хотелка, что бы информация записанная в базе была доступна еще и на других языках.
Интересно обсудить варианты решения, найти + и -.
Т.е. задача идентична городам и улицам. Решение предлагается то же.
По-моему, лучше всё же добавить в таблицу связей отдельный суррогатный ключ, и сделать связи City 1 - * CityLang * - 1 Lang. Но я в базах данных не настолько силён. Как там будет обрабатываться составной ключ, если удалить или обновить, скажем, запись в таблице языков. Одни говорят, что это медленнее, чем когда есть отдельный простой суррогатный ключ для записи, а не составной из айдишников связанных записей. Другие говорят, что дополнительный суррогатный ключ не нужен. Хотя его наличие ничего особо не усложняет и места силно не занимает.
Исключая того, что городов и улиц в базе может не быть вообще.
И не обязательно база реляционная и не обязательно только одна
Я не очень понимаю "нереляционная база данных". Это та, в которой нет связей между таблицами на уровне модели БД - т.е. вы их просто не заводите? Или это та, где сами данные не связаны по сути? Если данные всё же связаны по сути, а вы им связи в БД не делаете, то значит, вы должны их всё равно связать где-то в другом месте.
Как предлагал Мурр, вы можете локализованные данные хранить хоть в ДЛЛках, хоть в ресурсных файлах (как у меня). Но всё равно где-то должны будете прописать, что этот файл относится к такой-то локали и в нём лежит строка, хранящая имя города, например. Т.е. в той же БД создать таблицу, где всё это указать. Т.е. не вижу смысла выходить за рамки относительной БД, если отношения между сущностями в реальном мире так и так есть. Разве что кто-то раньше уже написал всё это именно в нереляционном стиле, а теперь нужно прикрутить локализацию. Ну значит, придётся городить реляционный костыль, покрывая нереляционные данные.
Исключая того, что городов и улиц в базе может не быть вообще.
И не обязательно база реляционная и не обязательно только одна
Крысота. Сначала спросить как решить проблему постройки велосипеда, а потом жаловаться что найденное решение не работает для строительства нефтеналивного причала.
Что надо-то? id-язык-перевод куда-то запихни. Хошь ресурсы, хошь РБД, хошь NoSQL, хошь через REST доступ к данным в CDN делай. Но ни в коем разе не записи для каждого языка "City_EN, City_DE" или лепить несколько переводов в одну запись "Köln|Cologne".
Но ни в коем разе не записи для каждого языка "City_EN, City_DE" или лепить несколько переводов в одну запись "Köln|Cologne".
Почему? Очень быстрое и простое решение. Может, там большего и не требуется.
Если бы кто-то где-то в мире обладал статистикой по принятым архитектурным решениям (пусть даже в разных областях), то уверен, что подобные бы превалировали с большим отрывом.
Почему? Очень быстрое и простое решение. Может, там большего и не требуется.
Такое решение вообще существовать не должно. Только в скриптике, написанном за 15 минут и через 2 дня забытом.
Медленное, хрупкое, плохо скалируется.
то уверен, что подобные бы превалировали с большим отрывом.
Не сомневаюсь. "95% людей - идиоты"
И с задержкой перевода, страницу ведь можно показать только после полного перевода всего что там есть.
Вообще база данных нужна в основном для поиска. Я бы перевод хранил бы в XML или в JSON формате. Когда буду делать один проект, всё будет храниться в формате HTML или в формате JSON.
Если не писать дурацких запросов с условиями, где вытаскиваются длинные строковые поля, что-то там сравнивается, сплитится, мерджится, а тупо по айдишникам и связям, то всё будет работать быстро и чётко. А всякие интероперабилити с подгрузом ДЛЛек, открытием файлов, чтением их и прочая муть сожрёт всю производительность. Толкай всё в БД и не думай, если объёмы не сверхбольшие.
Я так понимаю некий глобальный ресурс? А как потом редактировать запись в таблице, через посредника?
Да кто ж тебя знает. Куда надо. Что ты делаешь-то? Может тебе надо десктопное приложение, способное работать в оффлайне. Тогда отдельная ДБ и доступ к онлайн ресурсам слегка затруднён. А может клиент-сервер? Тогда ДБ хорошее решение. А может веб-приложение доступное по всему миру? CDN в руки. Редактировать часто будем? Да - скорее БД. Нет - скорее CDN/ресурсы. Объём данных? Большой - БД/CDN. Маленький - ресурсы. Крохотный - да хоть в код влепи.
И как он интересно тута попадёт?
Так-же как и в БД. Только XML это устаревший вариант, сейчас модно JSON. Пример:
index.html:
<!DOCTYPE html>
<head>
<title>Test</title>
<script>
var lang = 'ru';
window.onload = () => {
fetch('demo.json').then(response => response.json()).then(data => {
let json_items = JSON.parse(JSON.stringify(data));
let el = document.getElementById('city');
for(let index=0; index<json_items.cities.length; index++) {
let new_el = document.createElement('option');
new_el.setAttribute('value', json_items.cities[index].id);
new_el.innerHTML = json_items.cities[index][lang];
el.appendChild(new_el);
}
});
}
</script>
</head>
<body>
<select id="city">
</select>
</body>
demo.json:
{"cities":
[
{"id":1, "ru":"Moskva", "de":"Moskau", "en": "Moscow"},
{"id":2, "ru":"Keln", "de":"Köln", "en":"Cologn"}
]
}
Результат см. https://i.ibb.co/LQkd6QJ/json-demos-result-min.jpg
Вообще если использовать NOSQL то проблема решается в два счёта. См.:
https://i.ibb.co/Kyz0zG5/mongo0-min.jpg