Вы только что сократили raw-данные в надежде на то, что "серия 306 невозможна". А что если станет возможна, что будете делать с человеком со старым паспортом?
Вероятность того, что серия 306 станет возможной и будет отличаться от серии 0306 гораздо ниже вероятности того, что, например, серия станет пятизначной с добавлением числового суффикса из-за превышения количества выдаваемых паспортов в промежуток времени в московском регионе. Это очевидно просто из сути разрядов серии (код окато + код бланка). При этом, решение автора ломается на 5 значности, а bigint нет.
Зачем изощряться и стрелять себе в ногу, если можно не стрелять?
Потому что тут нет никакого выстрела в ногу, это вполне приемлемое решение.
Но зачем изначально создавать себе проблему на уровне хранения (терять данные)
В хранении bigint-ом нет никакой потери данных. Нет коллизий, из хранимого значения однозначно восстанавливается отображаемое значение и обратно. Так можно вообще заявить, что хранение дат timestamp-ом - это потеря данных.
чтобы потом героически её решать через View?
Хранение bigint-ом не требует никакого ощутимого оверхеда в части разработки и развития. Ну и суть подобного решения очевидна - это повышение производительности. Меня изначально смутило заявление, что по производительности индексов bigint и char(10) " разница практически нулевая ". Мой опыт, да и просто банальная логика говорит об обратном. Загрузить два значения в два регистра и сделать cmp гораздо быстрее, чем побайтово грузить строки и cmp их.
Меня это заинтересовало и я набросал простейший тест - инсёртим N номеров, ребилдим индекс, проверяем M номеров (90% существующих, 10% несуществующих). У меня получилось, что CHAR(10) минимум в полтора раза медленнее BIGINT и чем больше N, тем больше разница, конечно же.
Естественно, далеко не всегда нужно гнаться за этой производительностью, но с учётом того, что это практически ничего не стоит в части оверхеда, то BIGINT вполне себе жизнеспособный вариант, наряду с CHAR(10). А CHAR(10), например, будет быстрее в извлечении кусков серии, чем BIGINT.
если МВД добавит пятую цифру, букву или дефис, тип CHAR или VARCHAR мигрировать/расширить гораздо проще
То ваша схема просто ляжет с ошибкой транкейта и потребуется доработка физического хранилища.
А вот если вы заложились на INTEGER, то при появлении букв ваша схема просто ляжет с ошибкой типизации.
То есть потребуется доработка физического хранилища.
А вот если МВД добавит пятую цифру в серию (что гораздо вероятнее, чем букву), то в случае BIGINT потребуется только доработка представления, а в случае CHAR(10) - хранилища.
Представьте: завтра к этой базе подключается новый микросервис, BI-система для аналитики или понадобится сырая выгрузка в CSV. Каждому новому клиенту придется заново писать этот костыль с подстановкой нулей.
Нет, не придётся, в базах существуют представления.
Но, вообще говоря, мой комментарий был про то, что такой механизм хранения никак не ломает идентификацию человека.
Да и следуя вашей же аргументации, я могу вам сказать - представьте, что завтра в вашей базе начинают хранить не только российские, но и паспорта других стран. Или представьте, что завтра в вашей базе начинают хранить не только внутренние, но и загранпаспорта. Ваша предлагаемая схема готова к этому?
Паспорт серии 0306 и паспорт серии 306 – это юридически разные документы.
Разве количество цифр в серии не всегда равно 4? Потому что я не очень понимаю, какая проблема в том, чтобы хранить 0306 как 306, если серия 306 невозможна. Никто не мешает отображать 306 как 0306, при этом.
Любой платеж ЖКХ с банковской карты это персональные данные
Данные лица, на которое оформлен договор, у всех этих организаций есть и так, без каких-либо платежей. Данные банковских карт этим организациям не передаются.
Никаких даже местных консультантов. И, упаси боже, никаких русскоязычных.
Есть определённая ирония в том, что и статья автора является консультацией от русскоязычного. То есть автор заложил оригинальную пасхалку - предложил игнорировать свою статью в самой статье.
То есть, грубо говоря, расходы операторов на администрирование этого процесса должны быть заложены в стоимость других услуг оператора, либо в госрасходы (если предполагается дотировать операторам эти расходы). Отличный план, вполне в стиле других государственных решений.
Интересный подход. Так можно пользователей годами динамить с поддержкой любой технологии, в ожидании, пока она помрёт, а потом просто объявить, что оно и не было никогда нужно.
Если доход квалифицируется как доход физлица, итоговая нагрузка возвращается к привычным 13%+1%.
При заявленном доходе 9кк, итоговая нагрузка будет 16%+1%. Какая-то старая нейрохрень это писала что ли, с обучением на данных до 2021?
Но налоговая , налоговая может прийти к выводу, что доход связан с деятельностью российского ИП, и применить к нему УСН.
Однако ключевой вопрос заключается не в размере налога, а в устойчивости конструкции. Если налоговая сочтёт, что доход не связан с деятельностью ИП или что иностранная структура носит формальный характер, возможна переквалификация дохода и применение НДФЛ, что увеличит нагрузку до 13%. Это не неизбежный сценарий, но именно эта неопределённость
Нет тут никакой неопределённости. По аналогии со счётом ФЛ за рубежом, ИП может уведомить о наличии счёта за рубежом, который используется в деятельности ИП. После этого, он будет обязан подавать отчётность по этому счёту каждый квартал, причём разные налоговые могут требовать разных исходников от банка, вплоть до нотариального перевода.
у вас как пользователя не работают банки, это проблема конкретно вас
Ну нет, это проблема ублюдочного подхода компании эппл к навязыванию своей экосистемы. Не просто же так в европе эппл старательно продавливают на эти самые изменения в части деплоя и nfc.
Давайте представим ситуацию. Я однорукий человек и мне на скакалке скакать не нравится, ну неудобно. И вот я жалуюсь на производителей скакалок, что они обо мне не думают.
Аналогия - моё почтение.
Поэтому я предлагаю мыслить объективно.
Никакой объективности ни до, ни в этом комментарии не увидел. Речь о том, что, конкретно вас эппл устраивает и это прекрасно. Но не стоит пытаться делать из этого выводы космического масштаба (и глупости), про сравения открытости ведроида и айос. Вам же даже чтобы набросить говна на вентилятор в сторону ведроида приходится регистрировать мусорный акк, это уже очень забавный маркер.
Для меня техника от apple прекрасно работает из коробки. я не хочу тратить время на вопросы типа "какой там архитектуры у меня apk установится", где его найти, как получить рут (который кстати мне последний раз нужен был чтоб телефон на новую версию андроид установить). На вопросы типа, а как мне скинуть файл с телефона на комп без кабеля, как начать читать статью с телефона, а потом моментально открыть страницу браузера и все вкладки на ноуте.
По описанию проблем выглядит так, что у вас был какой-то ноунейм ведроид за $50. Берите ведроид за те же $1k+, что и айфон и никаких подобных вопросов у вас не возникнет.
Меня всегда последнее время веселят эти сомнительные тезисы.
Зачем, у меня все банки доступны из app store.
А банковские приложения банков РФ недоступны.
Более того, apple pay тоже прекрасно работает.
А банковские карты банков РФ не работают.
Оправдывать абсолютно искусственные ограничения от эппл по установке приложений из сторонних источников или по использованию NFC тем, что А ОНО МНЕ И НЕ НУЖНО, всегда выглядит очень потешно.
Тоже резануло глаза. Насколько я помню, до sp2 никакой активации не было вообще, а после sp2 все пираты переехали на VLK версию, где, опять же, никакой активации не было.
И догадаться, что про жену говорит не левый чувак увидевший, как отъезжает такси с адреса с красивой девушкой, а левый чувак который с этой девушкой внезапно записан в виртуальную семью Яндекса.
Или догадаться, что про жену говорит муж с белочкой, который только что вломил ей хорошенького леща, а теперь пытается как-нибудь узнать, куда она убежала на такси, чтобы приехать и добавить.
Оператор не должен ни о чём догадываться, у него есть скрипт, он работает по скрипту и оператор справился на отлично - не раскрыл информацию, которую не должен был раскрыть. Яндекс не должен предугадывать, какая моча ударит в голову какому клиенту.
Если клиент (как заявлено) переживает за родственников - яндекс уже предоставил ему массу возможностей за ними следить:
1) можно заранее попросить расшаривать трек
2) можно получать треки на почту по завершению
3) можно заранее подготовить возможность залогиниться от нужного аккаунта
Перекладывать свою шизу и неспособность воспользоваться нужным инструментарием на оператора, который отлично выполнил свою работу выглядит максимально непродуктивно.
Есть, например, бесплатный и довольно удобный https://github.com/Ylianst/MeshCentral - вполне неплохая self-hosted замена.
Вероятность того, что серия 306 станет возможной и будет отличаться от серии 0306 гораздо ниже вероятности того, что, например, серия станет пятизначной с добавлением числового суффикса из-за превышения количества выдаваемых паспортов в промежуток времени в московском регионе. Это очевидно просто из сути разрядов серии (код окато + код бланка). При этом, решение автора ломается на 5 значности, а bigint нет.
Потому что тут нет никакого выстрела в ногу, это вполне приемлемое решение.
Уже давно ответил
В хранении bigint-ом нет никакой потери данных. Нет коллизий, из хранимого значения однозначно восстанавливается отображаемое значение и обратно. Так можно вообще заявить, что хранение дат timestamp-ом - это потеря данных.
Хранение bigint-ом не требует никакого ощутимого оверхеда в части разработки и развития. Ну и суть подобного решения очевидна - это повышение производительности. Меня изначально смутило заявление, что по производительности индексов bigint и char(10) " разница практически нулевая ". Мой опыт, да и просто банальная логика говорит об обратном. Загрузить два значения в два регистра и сделать cmp гораздо быстрее, чем побайтово грузить строки и cmp их.
Меня это заинтересовало и я набросал простейший тест - инсёртим N номеров, ребилдим индекс, проверяем M номеров (90% существующих, 10% несуществующих). У меня получилось, что CHAR(10) минимум в полтора раза медленнее BIGINT и чем больше N, тем больше разница, конечно же.
Естественно, далеко не всегда нужно гнаться за этой производительностью, но с учётом того, что это практически ничего не стоит в части оверхеда, то BIGINT вполне себе жизнеспособный вариант, наряду с CHAR(10). А CHAR(10), например, будет быстрее в извлечении кусков серии, чем BIGINT.
То ваша схема просто ляжет с ошибкой транкейта и потребуется доработка физического хранилища.
То есть потребуется доработка физического хранилища.
А вот если МВД добавит пятую цифру в серию (что гораздо вероятнее, чем букву), то в случае BIGINT потребуется только доработка представления, а в случае CHAR(10) - хранилища.
То и вариант схемы, предложенный автором, перестанет удовлеторять требованиям.
Нет, не придётся, в базах существуют представления.
Но, вообще говоря, мой комментарий был про то, что такой механизм хранения никак не ломает идентификацию человека.
Да и следуя вашей же аргументации, я могу вам сказать - представьте, что завтра в вашей базе начинают хранить не только российские, но и паспорта других стран. Или представьте, что завтра в вашей базе начинают хранить не только внутренние, но и загранпаспорта. Ваша предлагаемая схема готова к этому?
Разве количество цифр в серии не всегда равно 4? Потому что я не очень понимаю, какая проблема в том, чтобы хранить 0306 как 306, если серия 306 невозможна. Никто не мешает отображать 306 как 0306, при этом.
Данные лица, на которое оформлен договор, у всех этих организаций есть и так, без каких-либо платежей. Данные банковских карт этим организациям не передаются.
Есть определённая ирония в том, что и статья автора является консультацией от русскоязычного. То есть автор заложил оригинальную пасхалку - предложил игнорировать свою статью в самой статье.
Так и matrix прекрасно бегает в контейнере на сервере.
То есть, грубо говоря, расходы операторов на администрирование этого процесса должны быть заложены в стоимость других услуг оператора, либо в госрасходы (если предполагается дотировать операторам эти расходы). Отличный план, вполне в стиле других государственных решений.
Зашквар зашкваром, а кушать всем хочется.
Интересный подход. Так можно пользователей годами динамить с поддержкой любой технологии, в ожидании, пока она помрёт, а потом просто объявить, что оно и не было никогда нужно.
gitea -> forgejo
https://forgejo.org/2024-02-forking-forward/
При заявленном доходе 9кк, итоговая нагрузка будет 16%+1%. Какая-то старая нейрохрень это писала что ли, с обучением на данных до 2021?
Нет тут никакой неопределённости. По аналогии со счётом ФЛ за рубежом, ИП может уведомить о наличии счёта за рубежом, который используется в деятельности ИП. После этого, он будет обязан подавать отчётность по этому счёту каждый квартал, причём разные налоговые могут требовать разных исходников от банка, вплоть до нотариального перевода.
Ну нет, это проблема ублюдочного подхода компании эппл к навязыванию своей экосистемы. Не просто же так в европе эппл старательно продавливают на эти самые изменения в части деплоя и nfc.
Аналогия - моё почтение.
Никакой объективности ни до, ни в этом комментарии не увидел. Речь о том, что, конкретно вас эппл устраивает и это прекрасно. Но не стоит пытаться делать из этого выводы космического масштаба (и глупости), про сравения открытости ведроида и айос. Вам же даже чтобы набросить говна на вентилятор в сторону ведроида приходится регистрировать мусорный акк, это уже очень забавный маркер.
По описанию проблем выглядит так, что у вас был какой-то ноунейм ведроид за $50. Берите ведроид за те же $1k+, что и айфон и никаких подобных вопросов у вас не возникнет.
Меня всегда последнее время веселят эти сомнительные тезисы.
А банковские приложения банков РФ недоступны.
А банковские карты банков РФ не работают.
Оправдывать абсолютно искусственные ограничения от эппл по установке приложений из сторонних источников или по использованию NFC тем, что А ОНО МНЕ И НЕ НУЖНО, всегда выглядит очень потешно.
https://f-droid.org/packages/org.vinaygopinath.launchchat
Тоже резануло глаза. Насколько я помню, до sp2 никакой активации не было вообще, а после sp2 все пираты переехали на VLK версию, где, опять же, никакой активации не было.
Пока смарттв идёт с нормальным hdmi, никакого смысла в поиске и покупке панелей без наворотов (которые якобы стоят дороже) нет.
Или догадаться, что про жену говорит муж с белочкой, который только что вломил ей хорошенького леща, а теперь пытается как-нибудь узнать, куда она убежала на такси, чтобы приехать и добавить.
Оператор не должен ни о чём догадываться, у него есть скрипт, он работает по скрипту и оператор справился на отлично - не раскрыл информацию, которую не должен был раскрыть. Яндекс не должен предугадывать, какая моча ударит в голову какому клиенту.
Если клиент (как заявлено) переживает за родственников - яндекс уже предоставил ему массу возможностей за ними следить:
1) можно заранее попросить расшаривать трек
2) можно получать треки на почту по завершению
3) можно заранее подготовить возможность залогиниться от нужного аккаунта
Перекладывать свою шизу и неспособность воспользоваться нужным инструментарием на оператора, который отлично выполнил свою работу выглядит максимально непродуктивно.