Тоже хотел изменить тип с varchar(12) на bigint, но:
1. Таблица - справочник организаций
2. ИНН и КПП храню в разных колонках.
3. В списке есть и ЮЛ и ИП ИНН у которых 10 и 12 цифр соответственно

Что имеем:
ИНН у меня - первичный ключ. Если будет филиал - будет бяка. Пока их нет и не планируется, но если уж переделывать, то надо учесть.
x.diabloНе знаю как в русских, но в украинских ИНН могут быть ведущие нули, причем значащие.
Потому, если ты надумал хранить его как число - то потом придется застрелиться.
Та же тема. Но не все так печально. Дописать нули в ответе можно таким запросом


Но проблема не решена. Я думаю, что ноль в начале может быть только один как у ЮЛ так и у ИП. То есть не может быть ИНН у ИП с тремя нолями впереди. А это решает задачу, но раздувает запрос. ИНН у меня primary key в таблице - справочнике и имеет много связей с другими таблицами. Как то вот все же хочется хранить цифры как число а не как текст. Но тут надо даже не беря во внимание филиалы, определиться что проще. Хранить как varchar(12) или дорисовывать нули при запросе.
Делать в такой таблице суррогатный ключ мне совершенно не хочется, т.к. связка двух колонок ИНН и КПП в справочнике фирм - дело уникальное. А суррогатный ключ не будет использоваться ни для чего. Индексы, запросы, сортировка, чтение, правка - он нафиг не нужен! Единственное что можно сделать, это связи с другими таблицами по нему. Но зачем? Там тоже есть ИНН которым сейчас все и связывается.
Как итог пока скажу так:
С типом varchar(12) На небольшой базе со справочником фирм в 5000 записей и несколькими связанными журналами по 50'000 записей, все летает. Необходимости в оптимизации вообще нет. Но если можно лучше, почему бы это не сделать.