При проектировании базы данных важно учитывать будущее вашей системы — как вы будете подходить к росту после масштабирования вашего бизнеса. Как правило, люди используют автоматически увеличивающиеся первичные ключи для маркировки каждой строки в таблице. Однако это может вызвать проблемы по мере роста вашей базы данных.
Один из способов обхода и лучшая практика при проектировании базы данных — использовать UUID (универсальный уникальный идентификатор). UUID — это число из 128 бут. Количество символов в этом идентификаторе позволяет ему быть уникальным среди других ключей в базе данных. UUID состоит из трех разных компонентов. К ним относятся ссылка на сетевой адрес хоста, сгенерировавшего идентификатор, отметка времени создания идентификатора, а также случайные символы для повышения вероятности уникальности (хотя вероятность уникальности все же не равна нулю).
При использовании автоматически увеличивающихся ключей новая созданная запись имеет первичный ключ, уникальный только для этой конкретной таблицы. Преимущество использования UUID заключается в том, что он позволяет вам иметь уникальные значения в нескольких базах данных. Это может пригодиться, если вы хотите создать таблицу, содержащую значения из двух или более разных таблиц.
Несмотря на очевидные преимущества использования UUID для баз данных, также важно отметить некоторые недостатки, которые важно учитывать при принятии решения о том, лучше ли использовать UUID для вашей системы. Хранилище UUID больше, чем у первичного ключа, что может привести к проблемам с производительностью. Кроме того, UUID сложнее упорядочить, чем автоматически увеличивающиеся первичные ключи, где порядок ясен.
Одним из реальных примеров масштабирования с помощью UUID является Project Mezzanine Uber, в котором они создали Schemaless, масштабируемое хранилище данных. Цель этого проекта состояла в том, чтобы увеличить объем памяти для поездок, так как компания быстро росла в 2014 году. Ключевым шагом стала замена идентификаторов поездок на UUID. Это позволило бы Uber добавлять новые столбцы и поля без перенастройки, поскольку поездки постоянно добавлялись в хранилище в любой момент.
Итак, при рассмотрении шаблонов проектирования в следующий раз, когда вы будете работать с базой данных, подумайте о долгосрочной перспективе, чтобы вам было легче масштабировать.
Источники:
https://www.sqlshack.com/understanding-the-guid-data-type-in-sql-server/
https://en.wikipedia.org/wiki/Универсальный_уникальный_идентификатор
