Преимущества и недостатки ключей базы данных GUID / UUID

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

кто-нибудь работал с GUID в базе данных? Какие преимущества я получу, если пойду этим путем, и каковы вероятные подводные камни?

200
database guid uuid

8 ответов

плюсы:

  • может генерировать их в автономном режиме.
  • делает репликацию тривиальной (в отличие от int, что делает ее очень сложной)
  • ОРМ обычно как они
  • уникальный во всех приложениях. Таким образом, мы можем использовать ПК из нашей CMS (guid) в нашем приложении (также guid) и знать, что мы никогда не получим столкновение.

недостатки:

  • большее использование пространства, но пространство дешево (er)
  • не могу заказать по ID, чтобы получить порядок вставки.
  • может выглядеть уродливо в URL, но на самом деле, WTF вы делаете, помещая реальный ключ DB в URL!?
  • сложнее выполнить ручную отладку, но не так сложно.

лично я использую их для большинства ПК в любой системе приличного размера, но я получил "обучение" на системе, которая была реплицирована повсюду, поэтому мы должны были их иметь. YMMV.

Я думаю, что дубликат данных вещь мусор - вы можете получить дубликаты данных, однако сделай это. Суррогатные ключи обычно не одобряют там, где я работаю. Мы используем WordPress, как системы:

  • уникальный идентификатор строки (GUID / что угодно). Никогда не отображается пользователю.
  • public ID генерируется один раз из некоторого поля (например, title - make it-title-of-the-article)

обновление: Таким образом, этот получает +1'ed много, и я подумал, что должен указать на большой недостаток GUID PK: кластеризованный Индексы.

Если у вас много записей и кластеризованный индекс на GUID, ваша производительность вставки будет сосать, поскольку вы получаете вставки в случайных местах в списке элементов (это точка), а не в конце (что быстро)

поэтому, если вам нужна производительность вставки, возможно, используйте auto-inc INT и создайте GUID, если вы хотите поделиться им с кем-то другим (т. е. показать его пользователю в URL)

204

@Matt Sheppard:

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

таким образом, у вас есть идентификатор клиента, который однозначно идентифицирует клиента, и вы убедитесь, что идентификатор известен клиенту (в счетах-фактурах), так что клиент и люди обслуживания клиентов имеют общую ссылку в случае, если им нужно общаться. Чтобы гарантировать отсутствие дублированных записей клиента, добавьте ограничение уникальности в таблицу либо с помощью первичного ключа в идентификаторе клиента, либо с помощью ограничения NOT NULL + UNIQUE в столбце идентификатор клиента.

затем по какой-то причине (о которой я не могу думать) вас попросят добавить столбец GUID в таблицу customer и сделать его первичным ключом. Если идентификатор клиента столбец теперь остается без уникальности-гарантия, вы просите будущих проблем во всей организации, потому что GUID всегда будут уникальными.

какой-то " архитектор "может сказать вам:" о, но мы справляемся с реальные ограничение уникальности клиента в нашем приложении уровня!". Право. Мода на то, что языки программирования общего назначения и (особенно) фреймворки среднего уровня постоянно меняются и, как правило, никогда не будут жить в вашей базе данных. И есть очень хороший шанс, что вам в какой-то момент понадобится доступ к базе данных, не проходя через настоящее приложение. == Тревога. (Но, к счастью, вы и" архитектор " давно ушли, поэтому вас не будет там, чтобы убрать беспорядок.) Другими словами: поддерживайте очевидные ограничения в базе данных (и на других уровнях, если у вас есть время).

другими словами: могут быть веские причины добавить столбцы GUID в таблицы, но, пожалуйста, не поддавайтесь искушению сделать это понизьте ваши амбиции для последовательности внутри реальные (==не GUID) информация.

13

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

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

есть некоторые производительности такие проблемы, как фрагментация индекса. Но они легко разрешимы (comb guids от Джимми Нилсона:http://www.informit.com/articles/article.aspx?p=25862)

редактировать объединил мои два ответа на этот вопрос

@Matt Sheppard я думаю, что он имеет в виду, что вы можете дублировать строки с разными GUID в качестве первичных ключей. Это проблема с любым суррогатным ключом, а не только с GUIDs. И, как он сказал, это легко решить, добавив осмысленный уникальный ограничения для неключевых столбцов. Альтернативой является использование естественного ключа, и у них есть реальные проблемы..

11

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

9

Почему никто не упоминает производительность? Когда у вас есть несколько соединений, все на основе этих неприятных GUIDs производительность будет проходить через пол, был там : (

8

еще одна небольшая проблема с использованием GUID в качестве первичных ключей, если вы также используете этот столбец в качестве кластеризованного индекса (относительно распространенная практика). Вы собираетесь взять удар по insert из-за природы guid не начать последовательный в любом случае, таким образом, их будут разбиты страницы и т. д. при вставке. Просто нужно подумать, будет ли система иметь высокий IO...

6

первичные ключи-ids-versus-guids

стоимость GUID в качестве первичных ключей (SQL Server 2000)

мифы, GUID против автоинкремента (MySQL 5)

Это действительно то, что вы хотите.

uid Pros

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

GUID минусы

  • это колоссальный 4 раза больше, чем традиционное 4-байтовое значение индекса; это может иметь серьезные последствия для производительности и хранения, Если вы не будете осторожны
  • громоздкий для отладки (где userid= ' {BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
  • созданные GUID должны быть частично последовательными для лучшей производительности (например, newsequentialid () в SQL 2005) и для включения использования кластеризованных индексов
5

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

СУБД обычно обеспечивают уникальность первичных ключей и обеспечивают поиск по ключу в структуре под названием BTree, которая является деревом поиска с большим коэффициентом ветвления (двоичное дерево поиска имеет коэффициент ветвления 2). Теперь последовательный целочисленный идентификатор вызовет вставки только один сторона дерева, оставляя большинство узлов листьев нетронутыми. Добавление случайных UUID вызовет вставки для разделения листовых узлов по всему индексу.

аналогично, если данные хранятся в основном временные, часто бывает, что самые последние данные должны быть доступны и объединены против большинства. Со случайными UUIDs шаблоны не выиграют от этого и будут поражать больше строк индекса, тем самым нужно больше индексных страниц в памяти. С последовательными идентификаторами если самые последние данные необходимы больше всего, горячие страницы индекса потребуют меньше ОЗУ.

0