Всем доброго времени суток. Я только начинаю изучать MySQL и хочу построить БД по сотрудникам. Начал набрасывать идентификацию, которую решил построить на СНИЛС, так как в моей организации он обязателен. Посмотрев много видеоматериалов в которых предлагается брать за id XXX-XXX-XXX YY снилс, но тут вдруг наткнулся на статью, в которой дается математическая расшифровка этой комбинации а именно: Страховой номер индивидуального лицевого счета страхового свидетельства обязательного пенсионного страхования(он же СНИЛС) проверяется на валидность контрольным числом. СНИЛС имеет вид: «XXX-XXX-XXX YY», где XXX-XXX-XXX — собственно номер, а YY — контрольное число. Алгоритм формирования контрольного числа СНИЛС таков:

1) Проверка контрольного числа Страхового номера проводится только для номеров больше номера 001-001-998

2) Контрольное число СНИЛС рассчитывается следующим образом:

2.1) Каждая цифра СНИЛС умножается на номер своей позиции (позиции отсчитываются с конца)

2.2) Полученные произведения суммируются

2.3) Если сумма меньше 100, то контрольное число равно самой сумме

2.4) Если сумма равна 100 или 101, то контрольное число равно 00

2.5) Если сумма больше 101, то сумма делится по остатку на 101 и контрольное число определяется остатком от деления аналогично пунктам 2.3 и 2.4

ПРИМЕР: Указан СНИЛС 112-233-445 95
Проверяем правильность контрольного числа:
цифры номера 1 1 2 2 3 3 4 4 5
номер позиции 9 8 7 6 5 4 3 2 1
Сумма = 1×9 + 1×8 + 2×7 + 2×6 + 3×5 + 3×4 + 4×3 + 4×2 + 5×1 = 95
95 ÷ 101 = 0, остаток 95.
Контрольное число 95 — указано верно
Данный алгоритм не способен обнаружить все случаи ошибок в одной цифре (например, номера 087-654-303 00 и 087-654-302 00 отличаются одной цифрой, но оба будут признаны верными). Также не во всех случаях может быть обнаружена ошибка перестановки двух соседних цифр (например, 087-654-303 00 и 086-754-303 00). Причина - пункт 2.4, где для близких чисел 100 и 101 установлено одинаковое контрольное число 00.

Если бы вместо пунктов 2.4, 2.5 применялся пункт

2.4') Если сумма равна или больше 100, то контрольное число равно двум последним цифрам этой суммы (остатку от деления суммы на 100),

то алгоритм был бы способен обнаружить все случаи ошибок в одной цифре и все случаи ошибочной перестановки двух соседних цифр. Проверил множество СНИЛС сотрудников и оказалось чистейшей правдой, и как после такого действовать? принять за ID суррогатный ключ, а куда девать номер???? разбивать его на числа и просто хранить их каждое в отдельном столбце, и использовать только для проверки правила??

Суррогатный ID я думаю представить так: надеюсь файл откроется у Вас. посмотрите поправьте меня если ннеправ

Akina, А можно тогда поинтересоваться как это будет в логической схеме, если несложно. вкратце что есть основной идентификатор, а какие данные это просто масса данных привязываемых к уникальному значению. Я имею виду: № снилс к нему автоинкримент который будет являться уникальным, а все остальные данный которые будет иметь id снилс такие как ФИО, пасплотныые данные, данные других документов будут иметь тот же ID что и снилс? как в дальнейшем поиск к примеру данных паспорта гражданина Иванова Ивана Ивановича со снилсом xxx-xxx-xxx yy имеющим id 00000001 будет осуществляться? как именно к этому id привязывать все остальное? В 2х словах, если не трудно

Akina,
Прочтем и будем надеяться что поймем!!!!

Akina,
Не подумайте что ленив, просто если есть возможность может посоветуете где есть интересный материал по данному поводу, так что бы доступным языком описано было. Нет можно конечно просто гуглить, но если Вам встречался интересный материальчик можно ссылочку.

Akina,

RTFM "Анализ предметной области". по такой абривиатуре вообще ничего не выдает