Передаю вам знания, пока вы их не испортили.
Чилийские RUT (или RUN, они практически одинаковы) — это то, что любят использовать большинство чилийских сервисов. Это решает проблему наличия одной уникальной точки данных, привязанной к уникальному существующему человеку, по сравнению с электронными письмами или даже телефонными номерами, которые можно легко сгенерировать и присвоить одному и тому же человеку.
RUT являются стандартными в Чили. Большинство сервисов и компаний позволяют сопоставлять RUT с другими данными, такими как финансовое состояние, подтверждение места жительства, справочные документы, зарегистрированные транспортные средства и так далее. Как человек, вы не стали бы использовать РУТ другого человека, у вас могут быть большие проблемы, так как это выдача себя за другое лицо преследуется по закону.
Вернемся к основной теме. Если в ваше приложение отправляется RUT, вам придется искать способ, как правильно его сохранить. Я видел много методов, но тот, который используется до сих пор, очень прост.
Краткий урок: RUT были созданы в 1969 году для финансовой идентификации человека или компании. Одна из особенностей заключалась в том, что они не могли подделывать на ходу, но мало ли вы знаете, что компьютеры появились несколько десятилетий спустя, которые делают это почти мгновенно.
Номер РУТ и проверочная цифра
RUT состоит из числа и проверочной цифры, последняя из которых представляет собой цифру между 0 и 9 или символ K. Так что часть «цифра» — это не цифра, а символ, но все говорят так, как есть.
Поскольку RUT уникальны для каждого человека и компании, вы никогда не получите RUT с тем же номером, но с другой проверочной цифрой. Кроме того, RUT никогда не переназначаются.
Проверочная цифра является результатом математического алгоритма над числом, описывать который для целей данной статьи нет смысла.
Хранение РУТ
Как вы, возможно, уже знаете, первая часть RUT — это просто целое число, тогда как другая часть может быть целым числом или символом. Поэтому лучший способ сохранить их в базе данных — использовать наших друзей int и char.
| number | verification_digit | | ---------- | ------------------ | | 6898742 | 3 | | 15846327 | K |
Номер РУТ
Числа RUT не могут быть отрицательными и могут достигать 90 миллионов.
Лучше всего хранить как целое число без знака. Он использует только 4 байта и допускает число до 2³² (4 294 967 295), поэтому вам не нужно учитывать какой-либо другой тип данных, рассчитанный на будущее… если только вы не запретите все противозачаточные средства в страна.
Проверочная цифра RUT
Цифру подтверждения можно хранить как фиксированную длину в один символ, поскольку она может быть целым числом или символом. Это составляет всего 1 байт.
Базы данных MySQL допускают ENUM, что позволяет столбцу хранить только значение из предопределенного списка значений. В этом случае, поскольку список равен 0–9 или K, мы могли бы его использовать, но лучше не будем. ENUM не является стандартом SQL.
В этих случаях CHECK проверит, находится ли устанавливаемое значение в списке допустимых значений, будучи типом varchar или целым числом. Но это не изменит тип данных столбца, а только добавит дополнительную нагрузку на вставку, которую можно передать самому приложению.
Использование int позволяет использовать числовой столбец в качестве индекса для быстрого поиска пользователей в базе данных и создания на его основе связей с другими таблицами.
Результирующий SQL-запрос
Мы можем начать с чего-то вроде этого:
CREATE TABLE `person` ( `rut_num` INT unsigned NOT NULL, `rut_vd` CHAR(1) -- ... more columns UNIQUE KEY `rut_num`, PRIMARY KEY (`rut_num`) );
Таким образом, мы получаем только 5 байтов данных для идентификации человека и 4 байта для каждой записи индекса.
Сохранение только номера
Другой метод заключается в том, чтобы полагаться на проверку RUT. Если в вашем приложении есть способ убедиться, что номер имеет правильный проверочный символ перед сохранением, вы можете легко избавиться от проверочной цифры.
| number | other info ...| | ---------- | ------------- | | 6898742 | | | 15846327 | |
При получении номера RUT вы можете указать своему приложению сгенерировать проверочную цифру или, что еще лучше, создать функцию SQL для автоматического добавления ее в столбец номера.
Это экономит только 1 байт данных, 20 % от размера данных RUT, но может быть меньше 1 % с учетом всей строки данных, которую вы хотите получить.
Это начинает звучать ужасно, если принять во внимание, что это увеличит нагрузку на приложение или базу данных. Только представьте, что вы извлекаете тысячи чисел и генерируете проверочную цифру для каждого из них!
Как насчет сохранения его в виде символов?
Ну... в этом большая проблема.
RUT может содержать от 8 до 12 символов, если добавить разделитель тысяч и дефис. Для переменного символа потребуется от 8 до 12 байтов, а использование столбца с фиксированной длиной 12 символов даст некоторую производительность при чтении, но вы будете использовать 240% пространства для тех же данных.
Кроме того, вам придется фильтровать входящие данные в вашем приложении и выбирать между использованием разделителя тысяч и дефиса или просто цифр и предполагать, что последний символ является проверочной цифрой для сохранения.
Так что да, не делайте этого, это просто добавляет больше логики там, где ее быть не должно.
Я сделал пакет PHP для этого
Поскольку большинству чилийских разработчиков приходится работать с RUT в своих общедоступных веб-приложениях, я позволил себе сделать пакет PHP для решения этой проблемы. Он имеет множество удобных функций для работы с RUT, таких как массовая генерация и проверка.
Хорошего 2019 года.
