Хранить язык (ISO 639) как номер

Question

Я работаю над базой данных MongoDB и до сих пор хранил некоторую информацию в виде чисел вместо строк, потому что я предполагал, что это будет более эффективно. Например, я храню страны, следующие по номеру ISO 3166-1 и по полу после ISO / IEC 5218 . Но до сих пор я не нашел аналогичного стандарта для языков, ISO 639 , по-видимому, не имеет соответствующего списка числовых кодов.

Каков был бы правильный способ сделать это? Должен ли я просто использовать строковые коды?

Спасибо!

Answer 1

Если вам не хватает производительности и / или вы хотите добиться действительно небольших размеров данных, я бы посоветовал вам использовать либо трехбуквенные (с более высокой степенью детализации), либо двухбуквенные (с более низкой степенью детализации) коды из IOC ISO -639-1 / 2 .

Насколько мне известно, для этого стандарта нет встроенного в какой-либо из известных мне языков программирования помощника или чего-либо еще, поэтому вам нужно создать свой собственный переводчик (код <-> полное имя), который, однако, должен быть тривиальным.

И, как уже упоминалось, вы должны сами оценить стоимость, связанную с этим (например, не иметь возможности просто посмотреть на данные и сразу же понять их) для себя. Лично я рекомендую сохранять размеры данных небольшими, поскольку разбор BSON и строковые операции ужасно дороги по сравнению с обработкой чисел (или более коротких строк в этом отношении). При работе с небольшими наборами данных это не будет заметно. Однако, если вам необходимо просмотреть миллионы документов или выполнить дополнительную оптимизацию, это может стать критически важным.

Answer 2

Если вы являетесь поклонником номеров, вы можете использовать коды вызова стран , хотя они "только" представляют членов МСЭ (193 страны согласно Википедии). Но эй, у них есть Сомали и Палестина, так что это хороший намек на то, насколько это глобально.

Однако сохранение всего в закодированном формате (цифры здесь) подразумевает этап декодирования на лету, когда запрашивается любой фрагмент данных (с таблицами перевода, хранящимися в ОЗУ, а не в ПЗУ БД). Вероятно, на сервере, процессор которого является ценным, но вы, возможно, депортировали проблему на клиенте, перегружая драгоценную, критичную ко времени связь сервер-клиент в процессе.

Итак, еще в 90-х годах, когда жесткий диск объемом 40 МБ был дорогим, это могло быть интересно. Сегодня стоимость хранения данных и стоимость обработки данных не совпадают с 1 ... Не считая времени, которое требуется вам для обдумывания и реализации преобразований. При всем том, что говорят «ИМХО», я думаю, что этот уровень эффективности фактически убивает эффективность. ;)

РЕДАКТИРОВАТЬ : Упс, только что понял, что я не в себе (этот глагол вообще существует?), Вопрос страны / языка. Страны вы уже разобрались, мой плохой. Я не знаю нумерованного списка языков. Тем не менее, вторая часть поста все еще может быть актуальной ...