Является ли более производительным иметь строки или столбцы в SQL?

Question

Если мне нужно сохранить много связанных строк, которые могут быть разделены на разных языках: как лучше это сделать?

Я думаю, у меня есть следующие варианты. Варианты 1 и 3 являются наиболее понятным для меня решением. У них больше столбцов, но меньше строк.

Варианты 2 и 4 являются наиболее гибкими (я мог бы динамически добавлять новые string_x без изменения базы данных). У них всего три столбца, но в результате будет много строк.

Опция 5 приведет к множеству таблиц.

Вариант 1:

id | string_1 | string_2 | string_3 | string_4 | ... | string_n | lang

Вариант 2 * (где имя будет строка_1 или строка_2 и т. Д.) *

id | name | lang

Вариант 3

id | string_1 | string_2 | string_3 | string_4 | ... | string_n
id | lang     | stringid

Вариант 4

id | lang | stringid
id | name

Опция 5

id | string_1 | lang
id | string_2 | lang
id | ...      |lang

Я использую его для хранения предварительно кэшированных значений html для нескольких представлений (одна строка, две строки, длинное описание и т. Д.), Если это представляет интерес.

Answer 1

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

Опция 5 не рекомендуется, так как вы получите строковый идентификатор (который является данными) в имени таблицы.Вы должны изменить дизайн базы данных, если хотите добавить еще одну строку.

Вариант 2 или 4 будет работать нормально.Вариант 4 более нормализован, поскольку у вас нет повторяющихся имен строк, но с вариантом 2 будет проще работать, если вы вводите значения непосредственно в табличное представление.

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

Answer 2

Если вы поддерживаете только несколько языков, вы можете также рассмотреть схему, в которой каждый язык является собственным столбцом:

ID    EN    ES    FR   Etc...

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

Answer 3

Это зависит от многих других вещей.Прежде всего, сколько строк может быть?Сколько языков может быть?Для упрощения, скажем, если какое-либо из этих чисел больше 5, то варианты 1 и 3 недопустимы.

Прежде чем идти дальше, вам определенно следует рассмотреть реализацию многоязычной функциональности вне базы данных.,В PHP вы можете использовать Gettext и помещать данные перевода в простые файлы.Это лучшая идея по нескольким причинам, основными из которых являются производительность и простота использования с внешними переводчиками.

Если вам абсолютно необходимо сделать это в базе данных, вам следует использовать структуру таблицы, подобную этой:

id | string | language

Примером записи может быть:

welcome_message | Hello, World! | english

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

Answer 4

Хотя мне не приходилось специально разбираться с многоязычными интерфейсами, и если это все, что его цель - перевод, я бы выбрал вариант 1, но поменял местами что-то вроде

id Английский Французский Немецкий Испанский и т. Д.

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