Является ли Guid лучшим типом данных идентификации для баз данных?
Он подключен к BI и слиянию данных из разных источников данных и сделает этот процесс более плавным.
и существует ли оптимальная стратегия миграции из базы данных без GUID в версию с GUID без потерь информации?
8 ответов
отредактировано после прочтения ответа Франса бумы, так как мой ответ был принят и поэтому перемещен на вершину. Спасибо, Франс.
GUIDs делают хорошее уникальное значение, однако из-за их сложной природы они не очень удобочитаемы, что может затруднить поддержку. Если вы собираетесь использовать GUID, вы можете рассмотреть вопрос о проведении анализа производительности операций с массовыми данными, прежде чем сделать свой выбор. Учтите, что если ваш первичный ключ "кластеризован", то GUID не подходят.
Это связано с тем, что кластеризованный индекс заставляет строки физически переупорядочиваться в таблице при вставках/обновлениях. Поскольку GUID являются случайными, каждая вставка потребует перемещения фактических строк в таблице, чтобы освободить место для новой строки.
лично мне нравится иметь два "ключа" на моих данных:
1) первичный ключ
Уникальные числовые значения с кластеризованным первичным ключом. Это внутренние ID для каждой строки и используется для уникальной идентификации строки и во внешних ключах.
Identity может вызвать проблемы, если вы используете репликацию базы данных (SQL Server автоматически добавит столбец "rowguid" для таблиц, реплицированных слиянием), потому что семя идентификатора поддерживается для каждого экземпляра сервера, и вы получите дубликаты.
2) внешний ключ / внешний ID / Business ID
Часто также предпочтительнее иметь дополнительную концепцию "внешнего идентификатора". Этот часто является символьным полем с уникальным ограничением (возможно, включая другой столбец, например идентификатор клиента).
Это будет значение, используемое внешними интерфейсами, и будет предоставляться клиентам (которые не распознают ваши внутренние значения). Этот "бизнес-идентификатор" позволяет клиентам ссылаться на ваши данные, используя значения, которые что-то значат для них.
имейте в виду, что GUID (или "unique_identifier") для ПК-плохой выбор, так как многие ПК имеют кластеризованный индекс (поэтому все строки хранятся на диске в индексированном порядке). Поскольку GUID являются случайными, не уверен, что новая строка будет добавлена в конце индекса, но может быть вставлена в середине индекса. Это приводит к уничтожению диска, поскольку строки должны быть перемещены.
Если вы считаете guid, по крайней мере, используйте sqlserver 2005 или up и NEWSEQUENTIALID() для значения PK, чтобы получить последовательные guid, которые всегда больше последнего, поэтому всегда добавляются в конце индекса. Если вы не используете sqlserver (но, например, postgresql или вы используете oracle и используете CHAR (32) или другой тип), рассмотрите COMB (см.:http://www.informit.com/articles/article.aspx?p=25862)
вероятно, вам понадобится средство для отслеживания источника для целей аудита, особенно в отношении финансовых данных.
даже если вы используете синтетические ключи в своей складской системе (что вы почти наверняка хотите сделать, если у вас есть несколько источников данных), вам все равно нужно будет поддерживать аудит. Поместите столбец "источник данных" и "естественный ключ" в таблицы в вашей системе и заполните их кодом для источника и представлением того, что однозначно идентифицирует запись в источник.
Если вы это сделаете, синтетические ключи должны быть только ints или numerics достаточно широкими, чтобы хранить достаточно значений (ints if
все, что может однозначно идентифицировать запись, является хорошим типом данных идентификации. GUID обычно хорош, но это не оптимальная идентичность, если у вас действительно есть уникальный идентификатор, поступающий из исходных данных. GUID-это случайное целое значение, которое гарантированно будет уникальным; однако в ситуации интеграции часто требуется обнаружить дубликаты информации, а не просто сопоставить записи.
нет" лучшего " типа данных идентификации. Различные варианты имеют различные сильные и слабые стороны. Я использую GUID чаще, чем нет, но мне приходится регулярно иметь дело с отключенными клиентами и репликацией слиянием, поэтому выбор уместен. Если вам не нужно иметь дело с репликацией (т. е. ситуация, когда пользователь добавляет новые записи при отключении от центральной базы данных), лучшим выбором является автоматическое увеличение поля int.
GUID лучше в сценариях репликации данных, с подходом" идентичность " вы должны быть осторожны, чтобы не вызвать коллизии между реплицируемыми данными между базами данных. Надеюсь, это поможет.
раньше мне совсем не нравился GUID, но я полюбил его. Я люблю его, потому что он относительно однороден и принят, и в конечном итоге я пишу меньше кода, используя его и поддерживая этот код, чем я обычно пишу и поддерживаю.
Это особенно полезно для хранения файлов, где вам нужно гарантировать, что имя файла уникально, в каталоге с потенциально большим количеством файлов, включая ранее существующие файлы.