Оптимизация: сохранение языка ISO 639-3 в столбце MySQL (язык int language_id или varchar)

Question

У меня есть БД MySQL, которая должна быть быстрой в масштабе.

Вариант 1 Таблицы могут хранить код языка ISO 639-3 в виде столбца: varchar(3) language

Вариант 2 Таблицы могут хранить идентификатор языка в виде столбца: int(2?) language_id, и может быть таблица языков с кодом ISO 639-3.

Вопрос Что имеет смысл для скорости в масштабе? Вариант 1 легче читать в БД. Я бы предпочел, чтобы скорость была одинаковой или совершенно незначительной даже в масштабе.

Спасибо!

Answer 1

Я рекомендую:

      CREATE TABLE ...
    ISO_630_3 CHAR(3) CHARACTER SET ascii

Это будет 3 байта, что меньше, чем INT(4 байта) and not much bigger thanSMALLINT UNSIGNED` (2 байта).

(Правильно ли я говорю, что коды всегда состоят из 3 букв ascii? Следовательно, нет необходимости в VAR, который занимает один или два дополнительных байта.)

CHAR(3)легко индексируется. Нет существенного преимущества в «нормализации» даже до smallint. Это по-прежнему применимо даже в масштабе миллиарда строк.

И, как вы заметили, «легче читать» чего-то стоит.

Если вы также храните текст, я предполагаю, что весь такой текст может быть сопоставлен с UTF-8? Если это так, используйте

           my_text TEXT CHARACTER SET utf8mb4

В MySQL нет проблем с наличием разных столбцов в одной таблице с использованием разных наборов символов (или сопоставлений).

Возможно, стоит отметить... Многие языки можно обнаружить по шестнадцатеричной кодировке utf-8:

      ⚈  Cxyy -- More Western Europe: Latin (C3-CA), Combining Diacritical Marks (CC-CD), Greek (CE-CF)
⚈  Dxyy -- Cyrillic (D0-D4), Hebrew (D6-D7), Arabic/Persian/Farsi (D8-DB), etc
⚈  E0yyyy -- various Indian character sets, southern Asia, etc.
⚈  E1yyyy -- Cherokee, Balinese, Khmer, Mongolian, Vietnamese, etc.
(etc)

-- http://mysql.rjweb.org/doc.php/charcoll#diagnosing_charset_issues