Как правильно хранить ИНН в бд MySQL?

Question

[Arris]

Возникла необходимость хранить в БД ИНН (несущественно, физлица или юрлица) и очень часто искать по нему.

Как известно, это последовательность из 10 (или 12) арабских цифр, возможно с ведущим нулём.

Вдумчиво погуглил. Подавляющее большинство источников рекомендует хранить это как varchar(12), использовать индекс и не заморачиваться. Иногда советуют использовать char(12) charset latin1. Но это всё равно строка, а искать по строкам я не люблю.

Я нашел решение, которое мне кажется идеальным:
`inn` decimal(10,0) ZEROFILL DEFAULT NULL
(decimal(12,0) соотв для физического лица )

Какие подводные камни я не заметил?
Спасибо.

Comments

[Алексей Уколов]

c2.com/cgi/wiki?PrematureOptimization

Answer 1

[Станислав Макаров]

возможно с ведущим нулём

Но это всё равно строка

вы сами ответили на свой вопрос.

char(12) charset latin1

Да, это хороший совет. Абсолютно бессмысленно и глупо использовать varchar для строк постоянной длины.

а искать по строкам я не люблю

А если перейти от личных предпочтений к реальным измерениям - действительно ли будут проблемы?

Comments

[Arris]

Читайте ниже :) Там есть более интересное решение. Как ЛИЧНО МНЕ кажется, искать (даже с индексом) по числовому полю лучше, чем по строковому.

[Станислав Макаров]

Arris ваш ответ я прочёл полностью, включая решение с decimal. Не вижу в нём особого смысла по ряду причин.
> Как ЛИЧНО МНЕ кажется, искать (даже с индексом) по числовому полю лучше, чем по строковому.
Тут такой момент, что строковое поле ПОСТОЯННОЙ длины не так уж медленнее при индексации и LIKE 'AAA%s' поиске. Хотя, дать конкретные советы и рекомендации лучше на конкретной СУБД.

[Arris]

Станислав Макаров: LIKE-поиск не используется. К чему нам искать ИНН-ы, ПОХОЖИЕ на какие-то другие ИННы? Только точное соответствие.

[Arris]

Станислав Макаров:
> А если перейти от личных предпочтений к реальным измерениям
проблем пока нет. А вот будет ли прирост - мне трудно замерить :(

[Станислав Макаров]

Arris

> К чему нам искать ИНН-ы, ПОХОЖИЕ на какие-то другие ИННы?
Очевидно, для live-поиска - классический случай применения.

Раз точное совпадение, почему думаете, что будут проблемы с поиском? Индекс будет использоваться.

[Станислав Макаров]

Arris прирост в случае decimal? Не думаю, что оно будет стоить потенциальных проблем.

[Arris]

Станислав Макаров: вооот. А я про проблемы и спрашиваю. Какие, по вашему, могут быть проблемы?

[Arris]

Станислав Макаров:
> Очевидно, для live-поиска - классический случай применения.
Хоть убейте, не вижу практического смысла в случае ИНН. Я понимаю еще фамилия или адрес...

[Станислав Макаров]

Arris вы видимо не поняли про ведущий ноль)

Понимаете, вы можете работать с ИНН двумя способами.
Первый способ называется "не заморачиваться". Это значит, что вы не пытаетесь как-либо интерпретировать строку ИНН. Раз вы не пытаетесь её интерпретировать, то вам и хранить её надо целиком и как есть. Если хранить её целиком и как есть - это именно строка, а не номер, т.к. ведущий ноль нужно сохранять. Если вы будете использовать числовой тип данных без особой осторожности, вы рано или поздно этот ноль потеряете (при распечатке документов например).

Второй способы называется" заморочиться и распарсить ИНН". Тогда уж вообще стоит разбить ИНН на составляющие и хранить их в отдельных полях, а контрольные цифры не хранить вообще, т.к. они по сути избыточны. Но тогда вам придётся разбирать/собирать ИНН при работе с БД. Нужно это вам или нет - зависит от задачи. Возможно, налоговая у себя так и делает, чтобы построить индексы для быстрого поиска по отдельным регионам и отделениям, и собирает ИНН на лету при отображении пользователю.

Эти способы альтернативны друг другу. Не стоит их бездумно совмещать. Вы поняли разницу между ними?

[Arris]

Станислав Макаров: вот именно такого ответа я и ждал изначально. Спасибо за разъяснение.