Является ли Guid лучшим типом данных для баз данных?

Question

Он связан с BI и объединением данных из разных источников данных и сделает этот процесс более плавным.

И существует ли оптимальная стратегия перехода с базы данных без Guids на версию с Guids без потери информации?

Answer 1

Имейте в виду, что GUID (или «unique_identifier») для PK - плохой выбор, поскольку многие PK имеют кластеризованный индекс (поэтому все строки хранятся на диске в индексированном порядке). Поскольку GUID являются случайными, нет уверенности, что новая строка будет добавлена ​​в конец индекса, но может быть вставлена ​​в середину индекса. Это вызывает разрушение диска, так как строки должны быть перемещены.

Если вы рассматриваете guid, по крайней мере используйте sqlserver 2005 или выше и NEWSEQUENTIALID () для значения PK, чтобы получить последовательные guid, которые всегда больше, чем последние, поэтому всегда добавляются в конце индекса. Если вы не используете sqlserver (но, например, postgresql или oracle и используете CHAR (32) или другой тип), рассмотрите COMB (см .: http://www.informit.com/articles/article.aspx?p=25862)

Answer 2

Отредактировано после прочтения ответа Франса Бума, так как мой ответ принят и, следовательно, перемещен наверх. Спасибо, Франс.

GUID действительно имеют уникальную ценность, однако из-за их сложной природы они не очень удобочитаемы, что может затруднить поддержку. Если вы собираетесь использовать GUID, вы можете подумать о том, чтобы выполнить некоторый анализ производительности операций с большими объемами данных, прежде чем сделать свой выбор. Примите во внимание, что если ваш первичный ключ «кластеризован», то GUID не подходит.

Это связано с тем, что кластеризованный индекс приводит к физическому переупорядочению строк в таблице при вставках / обновлениях. Поскольку идентификаторы GUID являются случайными, для каждой вставки потребуется перемещение фактических строк в таблице, чтобы освободить место для новой строки.

Лично мне нравится иметь два "ключа" в моих данных:

1) Первичный ключ
Уникальные числовые значения с кластеризованным первичным ключом. Это внутренний идентификатор моей системы для каждой строки, который используется для уникальной идентификации строки и внешних ключей.

Удостоверение может вызвать проблемы, если вы используете репликацию базы данных (SQL Server автоматически добавит столбец "rowguid" для таблиц с репликацией слиянием), поскольку начальное число идентификаторов сохраняется для каждого экземпляра сервера, и вы получите дубликаты.

2) Внешний ключ / Внешний идентификатор / Бизнес-идентификатор
Часто также предпочтительно иметь дополнительную концепцию «внешнего идентификатора». Это часто символьное поле с уникальным ограничением (возможно, включающее другой столбец, например, идентификатор клиента).

Это будет значение, используемое внешними интерфейсами, и будет доступно клиентам (которые не распознают ваши внутренние ценности). Этот «бизнес-идентификатор» позволяет клиентам ссылаться на ваши данные, используя значения, которые что-то для них значат.

Answer 3

Вероятно, вам понадобится средство, чтобы отследить источник, для целей аудита, особенно по финансовым данным.

Даже если вы используете синтетические ключи в вашей системе хранилища (что вы почти наверняка захотите сделать, если у вас несколько источников данных), вам все равно потребуется поддержка аудита. Поместите столбцы «Источник данных» и «Естественный ключ» в таблицы в вашей системе и заполните их кодом для источника и представлением того, что однозначно идентифицирует запись в источнике.

Если вы сделаете это, синтетические ключи должны иметь ширину только в целых или числовых значениях, чтобы хранить достаточно значений (в строках, если <4b строк, и чисел, если они закончены). Это означает, что они будут намного более читабельными, чем GUID. </p>

Answer 4

Следующий проект может быть полезным или, по крайней мере, вдохновить вас на решение этой проблемы.

https://github.com/twitter/snowflake

Answer 5

GUID лучше в сценариях репликации данных, с подходом «идентичности» вы должны быть осторожны, чтобы не вызвать коллизии между данными, реплицируемыми между базами данных. Надеюсь, это поможет.

Answer 6

Нет «лучшего» типа данных. Различные варианты имеют разные сильные и слабые стороны. Я использую GUID чаще, чем нет, но мне приходится регулярно иметь дело с отключенными клиентами и репликацией слиянием, поэтому выбор уместен. Если вам не нужно иметь дело с репликацией (то есть ситуация, когда пользователь добавляет новые записи, когда он отключен от центральной базы данных), лучше использовать автоматически увеличивающееся поле int.

Answer 7

Все, что может однозначно идентифицировать запись, является хорошим типом данных идентификации. GUID, как правило, хорош, но это не оптимальная идентификация, если у вас есть уникальный идентификатор, исходящий из исходных данных. GUID - это случайное целочисленное значение, которое гарантированно будет уникальным; однако в ситуации интеграции часто требуется обнаруживать дубликаты информации, а не просто сопоставлять записи.

Answer 8

Раньше мне совсем не нравился GUID, но я полюбил его. Мне это нравится, потому что он относительно однороден и принят, и в итоге я пишу меньше кода, используя его и поддерживая этот код, чем я обычно писал бы и поддерживал.

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