болталка

[sandro123]

Кому-то уже попадалась на глаза нашумевшая сегодня база? Имеется ввиду: [External Link Removed for Guests]

скорее всего наткнулись на супер мега компиляцию из баз, а раздули как всегда

[putler-24]

Судя по всему, там сборная солянка.

[Forsunka]

Доброго времени суток.

Как быть, если есть большой файл dbf и его не открыть в dbf viewer 2000? Программа просто падает и все. Файл весит 16 гб. Достоверно известно, что он целый, просто не хватает ресурсов в системе его открыть. Другие вьюверы работают еще хуже...

[[N]etwork[P]irate]

Кто-то проверял базу RussianTAX 2022 на корректность данных? Сразу было видно что в фамилии, имени или отчестве присутствует ошибка в кодировке, имеется ввиду что фамилия и отчество корректные, а имя неожиданно испорченно. Вчера я выложил комбинации ИНН + СНИЛС которые были проверены с помощью контрольного числа, возможно кому-то они действительно пригодятся для обогащения по ИНН или СНИЛС, но возникает вопрос, не могли ли они быть подделкой с заранее подогнанной суммой в контрольном числе, или такое ещё никогда не наблюдалось? Решил спросить, ибо чёрт знает, как сейчас, могут ухитриться те кто создаёт ложные данные для обмена на настоящие утечки. Буду благодарен за любое мнение относительно этой темы.

[[N]etwork[P]irate]

Пожалуй, стоит рассказать, какой именно опыт я приобрёл, исследуя комбинации ИНН + СНИЛС из базы RussianTAX 2022.

Первым делом, конечно же, была выполнена фильтрация и нормализация как ИНН, так и СНИЛС: удаление пустых значений и приведение к формату для юридических или физических ИНН. То есть, если длина ИНН была 9, добавлялся ведущий ноль (юридический ИНН), если длина 11 - также добавлялся ведущий ноль (физический ИНН). Значения длиной менее 9 удалялись сразу.

В итоге оказалось, что юридических лиц в выборке фактически не оказалось. Забыл ещё упомянуть, что перед добавлением ведущих нулей я удалил все значения, в которых не содержалось ни одной цифры, используя регулярное выражение. Таким образом, пустые значения тоже были удалены, что ускорило очистку данных.

СНИЛС - более специфический идентификатор. Как и с ИНН, я удалил все записи, не содержащие ни одной цифры, и привёл длину значений к 11 символам с ведущими нулями.

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

Далее началась проверка по контрольному числу: все комбинации, где ИНН или СНИЛС не проходили эту проверку, удалялись. После этого я проверил ИНН на начало с "00" и обнаружил такие значения. Это не ошибка расчёта контрольного числа, такое действительно может встречаться. Поэтому я удалил все ИНН, начинающиеся на "00".

Для СНИЛС сначала проверил начало на "000", таких значений не нашлось. Это позволяет сделать вывод, что СНИЛС технически не может начинаться на "000" (по крайней мере исходя из объёма данных в 27 миллионов). В то же время СНИЛС спокойно может начинаться на "00". Поэтому по СНИЛС дополнительных удалений не потребовалось. Но стоит учитывать, что СНИЛС вида "00000000505" может быть корректным с точки зрения контрольного числа, как и ИНН, поэтому даже после проверки контрольным числом желательно фильтровать такие значения по началу "000".

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

В итоге удалось отсеять некорректных комбинаций порядка 150-250 тысяч, что при общем объёме ≈28 миллионов записей составляет совсем немного. Таким образом, в подавляющем большинстве случаев встретились корректные комбинации ИНН + СНИЛС.

P.S. С начала 2019 года СНИЛС оформляется в виде 10-значного номера без контрольного числа, что затрудняет его проверку на корректность привычным алгоритмом.

[Strannik]

Доброго времени суток.

Как быть, если есть большой файл dbf и его не открыть в dbf viewer 2000? Программа просто падает и все. Файл весит 16 гб. Достоверно известно, что он целый, просто не хватает ресурсов в системе его открыть. Другие вьюверы работают еще хуже...

А если его подлить в СУБД мощные? SQLServer или Oracle умеют наверное dbf конвертировать