> достучаться до разрабов системы выдачи номеров и уточнения откуда и как эти номера берутся, выглядит не самой простой, но и не экстремально сложной для написания взвешенного материала.
На самом деле, необязательно конкретно до разработчиков системы, достаточно спросить любого программиста, работающего с базами.
В СУБД айдишники необязательно выдаются по порядку без пропусков. Даже, я бы сказал, по умолчанию они могут содержать пропуски, если специально это не отключить. Потому что айдишник — штука внутренняя и главное чтобы был уникальным = пропуски не так важны, как скорость их выдачи.
Как работает, например, Microsoft SQL Server: он может зарезервировать пул в 1000 айдишников. Потом, например, ты перезагрузил сервак или еще что, и этот пул пропал, а он возьмет еще 10к.
Из-за этого у тебя в базе будут записи, например, вот так:
1
2
3
1001
1002
1003
Последний айдишник 1003, а записей всего на самом деле шесть.
Как можно было бы оценить потенциальное количество пропусков по верхней границе. Например, перезагружали сервер они за это время раз 30. Это, максимум, до 30*1000=30000 пропусков. А если система на коленке написанное, то может и чаще ребутали.
И это еще мы не рассмотрели случай распределенных баз данных с шардированием по нескольким серверам (и параллельной обработкой): очевидно, нет никакой задачи везде сделать сквозной точно последовательный айдишник (напомню, id – штука чисто подкапотная).
Более того, если в системе люди, беспокоящиеся о безопасности, то не было бы никогда одной базы на всю россии. Как минимум, по отдельной на каждый федеральный округ — регион. А как уже они выделяли пулы под каждый регион — тоже может быть отдельной историей.
==
Другими словами, просто смотря на айдишники и не зная инсайдом точную схему их реализации во внутренних системах, я бы никакой вывод не делал. Плюс, как писали выше, еще и не зная, кого в эти базы добавляют (а флажок на qr не у всех).
Дискуссии пользователя
> достучаться до разрабов системы выдачи номеров и уточнения откуда и как эти номера берутся, выглядит не самой простой, но и не экстремально сложной для написания взвешенного материала.
На самом деле, необязательно конкретно до разработчиков системы, достаточно спросить любого программиста, работающего с базами.
В СУБД айдишники необязательно выдаются по порядку без пропусков. Даже, я бы сказал, по умолчанию они могут содержать пропуски, если специально это не отключить. Потому что айдишник — штука внутренняя и главное чтобы был уникальным = пропуски не так важны, как скорость их выдачи.
Как работает, например, Microsoft SQL Server: он может зарезервировать пул в 1000 айдишников. Потом, например, ты перезагрузил сервак или еще что, и этот пул пропал, а он возьмет еще 10к.
Из-за этого у тебя в базе будут записи, например, вот так:
1
2
3
1001
1002
1003
Последний айдишник 1003, а записей всего на самом деле шесть.
Вот почитайте подробнее, например, вот здесь: https://dba.stackexchange.com/questions/106209/unexpected-gaps-in-identity-column
Как можно было бы оценить потенциальное количество пропусков по верхней границе. Например, перезагружали сервер они за это время раз 30. Это, максимум, до 30*1000=30000 пропусков. А если система на коленке написанное, то может и чаще ребутали.
И это еще мы не рассмотрели случай распределенных баз данных с шардированием по нескольким серверам (и параллельной обработкой): очевидно, нет никакой задачи везде сделать сквозной точно последовательный айдишник (напомню, id – штука чисто подкапотная).
Более того, если в системе люди, беспокоящиеся о безопасности, то не было бы никогда одной базы на всю россии. Как минимум, по отдельной на каждый федеральный округ — регион. А как уже они выделяли пулы под каждый регион — тоже может быть отдельной историей.
==
Другими словами, просто смотря на айдишники и не зная инсайдом точную схему их реализации во внутренних системах, я бы никакой вывод не делал. Плюс, как писали выше, еще и не зная, кого в эти базы добавляют (а флажок на qr не у всех).