#breakfront_tooltips
Идентификаторы
В информационных системах, и особенно в их базах данных, необходимо использовать уникальные идентификаторы для объектов. Как правило, это числовые или текстовые поля.
Например, заказ в интернет-магазине мы все привыкли идентифицировать по номеру. Обычно это человекочитаемый код, вроде 34538.
Можно предположить, что всего у интернет-магазина на момент нашего заказа было 34537 заказов в базе. То есть в качестве идентификатора заказа система интернет-магазина генерирует десятичные целые числа путем автоинкремента. То есть при создании заказа БД прибавляет к Id последнего объекта 1.
Это довольно распространенная практика, простая в реализации и понятная всем людям. То есть директор интернет-магазина посмотрит на номер последнего заказа сразу поймет, сколько у него всего было заказов.
Но если директор поймет, то и конкурент поймет. Более того, конкурент может вычислить разницу номеров и понять, сколько заказов приходит в день, неделю, месяц. Так он поймет примерное количество клиентов, пики и спады продаж. И даже какие из наших маркетинговые активностей работают, а какие - нет.
Еще, если я на странице своего заказа вижу ссылку http://store.ru/order/3 - ничего не мешает мне заменить 3 на 2 и потенциально увидеть заказ другого пользователя. Если доступ к нему не закрыли, конечно. Однако часто этот доступ не закрыт:)
В общем, порядковый номер заказа в БД - чувствительная информация, часто закрытая договорами о неразглашении.
Что же делать? Можно путать следы: начинать отсчет с 10000, например. Но в целом от перечисленных опасностей это не спасает.
Часто используют какой-то составной код, сформированный по внутренней логике приложения. Например, “номер заказа в регионе”-”номер заказа у пользователя”. Кажется, примерно такой способ сейчас используют все крупные e-commerce игроки, когда показывают номер заказа покупателям. Потому что им важно, чтобы человек увидел свой заказ и не впал в ступор. Чтобы он мог где-то внести номер этого заказа или сказать его сотруднику магазина.
Этот способ не очень удобен тем, что нужно поддерживать внутреннюю логику генерации этих кодов. Особенно проблематично, если заказы создаются в разных экземплярах сервиса. Так что, возможно, внутри БД магазина скрыты другие кода - GUID или UUID.
GUID - Globally Unique Identifier, статистически уникальный 128-битный идентификатор. GUID выглядит так: b118c6e2-e0a5-4e83-81d3-8320a24eb8bf.
UUID - это аналогичный код, только формирующийся по другим правилам.
Самостоятельно guid’ы можно генерировать, например, здесь. Большинство программ для разработки включают в себя функции для генерации GUID/UUID.
GUID/UUID делают несколько сложнее взаимодействие человека с системой, а также имеют бОльший объем и могут несколько замедлить работу с БД.
Тем не менее, сейчас такие кода очень часто используют в качестве идентификаторов. И вот почему:
1) Уникальность - вероятность, что вы сгенерируете guid, который уже является где-то идентификатором настолько мала, что ей пренебрегают.
2) Сложно подобрать - простым перебором явно не получится.
3) Используется стандартный алгоритм генерации, не требующий закладывания специальной логики в приложение.
4) Не надо следить за уникальностью идентификаторов и актуальностью логики в разных частях системы.
В итоге, можно сделать вывод, что клиентам лучше показывать код, который никак нельзя “расшифровать”, чтобы получить информацию о заказе. А для внутренних процессов и разработки удобно использовать GUID или UUID.
Про техническую сторону сравнения GUID и автоинкремента можно почитать здесь.
Идентификаторы
В информационных системах, и особенно в их базах данных, необходимо использовать уникальные идентификаторы для объектов. Как правило, это числовые или текстовые поля.
Например, заказ в интернет-магазине мы все привыкли идентифицировать по номеру. Обычно это человекочитаемый код, вроде 34538.
Можно предположить, что всего у интернет-магазина на момент нашего заказа было 34537 заказов в базе. То есть в качестве идентификатора заказа система интернет-магазина генерирует десятичные целые числа путем автоинкремента. То есть при создании заказа БД прибавляет к Id последнего объекта 1.
Это довольно распространенная практика, простая в реализации и понятная всем людям. То есть директор интернет-магазина посмотрит на номер последнего заказа сразу поймет, сколько у него всего было заказов.
Но если директор поймет, то и конкурент поймет. Более того, конкурент может вычислить разницу номеров и понять, сколько заказов приходит в день, неделю, месяц. Так он поймет примерное количество клиентов, пики и спады продаж. И даже какие из наших маркетинговые активностей работают, а какие - нет.
Еще, если я на странице своего заказа вижу ссылку http://store.ru/order/3 - ничего не мешает мне заменить 3 на 2 и потенциально увидеть заказ другого пользователя. Если доступ к нему не закрыли, конечно. Однако часто этот доступ не закрыт:)
В общем, порядковый номер заказа в БД - чувствительная информация, часто закрытая договорами о неразглашении.
Что же делать? Можно путать следы: начинать отсчет с 10000, например. Но в целом от перечисленных опасностей это не спасает.
Часто используют какой-то составной код, сформированный по внутренней логике приложения. Например, “номер заказа в регионе”-”номер заказа у пользователя”. Кажется, примерно такой способ сейчас используют все крупные e-commerce игроки, когда показывают номер заказа покупателям. Потому что им важно, чтобы человек увидел свой заказ и не впал в ступор. Чтобы он мог где-то внести номер этого заказа или сказать его сотруднику магазина.
Этот способ не очень удобен тем, что нужно поддерживать внутреннюю логику генерации этих кодов. Особенно проблематично, если заказы создаются в разных экземплярах сервиса. Так что, возможно, внутри БД магазина скрыты другие кода - GUID или UUID.
GUID - Globally Unique Identifier, статистически уникальный 128-битный идентификатор. GUID выглядит так: b118c6e2-e0a5-4e83-81d3-8320a24eb8bf.
UUID - это аналогичный код, только формирующийся по другим правилам.
Самостоятельно guid’ы можно генерировать, например, здесь. Большинство программ для разработки включают в себя функции для генерации GUID/UUID.
GUID/UUID делают несколько сложнее взаимодействие человека с системой, а также имеют бОльший объем и могут несколько замедлить работу с БД.
Тем не менее, сейчас такие кода очень часто используют в качестве идентификаторов. И вот почему:
1) Уникальность - вероятность, что вы сгенерируете guid, который уже является где-то идентификатором настолько мала, что ей пренебрегают.
2) Сложно подобрать - простым перебором явно не получится.
3) Используется стандартный алгоритм генерации, не требующий закладывания специальной логики в приложение.
4) Не надо следить за уникальностью идентификаторов и актуальностью логики в разных частях системы.
В итоге, можно сделать вывод, что клиентам лучше показывать код, который никак нельзя “расшифровать”, чтобы получить информацию о заказе. А для внутренних процессов и разработки удобно использовать GUID или UUID.
Про техническую сторону сравнения GUID и автоинкремента можно почитать здесь.