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

Question

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

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

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

908 8

database guid uuid

8 ответов:

Comments

Ничего не найдено.

Nic Wise · Accepted Answer · 2017-02-13 04:31:32

плюсы:

может генерировать их в автономном режиме.

делает репликацию тривиальной (в отличие от int, что делает ее очень сложной)

ОРМ обычно как они

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

недостатки:

большая польза космоса, но космос дешев (Эр)

не могу заказать по ID, чтобы получить заказ на вставку.

может выглядеть некрасиво в URL, но на самом деле, WTF вы делаете положить реальный ключ БД в URL!?

труднее сделать ручную отладку, но не так сложно.

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

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

уникальный идентификатор для строки (GUID / whatever). Никогда не отображается для пользователя.

public ID генерируется один раз из некоторого поля (например, название - сделать его-название-статьи)

обновление: Так что это один получает +1 большое объед, и я думал, что я должен отметить большой минус это идентификатор ПК: кластерный Индексы.

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

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

Troels Arvin · Accepted Answer · 2008-09-07 21:05:27

@Matt Sheppard:

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

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

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

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

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

Mendelt · Accepted Answer · 2008-09-16 23:33:07

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

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

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

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

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

Troels Arvin · Accepted Answer · 2008-09-05 11:38:43

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

Andrei Rînea · Accepted Answer · 2008-09-06 04:05:27

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

WIDBA · Accepted Answer · 2008-09-16 05:40:09

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

wener · Accepted Answer · 2013-10-26 11:13:02

основная-ключи-идентификаторы и идентификаторы GUID

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

мифы, GUID против Autoincrement (MySQL 5)

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

UID Pros

уникальный для каждой таблицы, каждой базы данных, каждого сервера

позволяет легко объединять записи из разных баз данных

позволяет легко распределение баз данных по нескольким серверам

вы можете генерировать идентификаторы в любом месте, вместо того, чтобы туда и обратно в базу данных

большинство сценариев требуют репликация столбцов идентификаторов GUID в любом случае

GUID минусы

это колоссальные 4 раза больше, чем традиционное значение индекса 4 байта; это может иметь серьезные последствия для производительности и хранения, Если вы не будете осторожны

громоздкий для отладки (где userid= ' {BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')

созданные GUID должны быть частично последовательными для лучшей производительности (например, newsequentialid () на SQL 2005) и для включения использования кластеризованных индексов

Antti Haapala · Accepted Answer · 2017-11-29 18:57:39

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

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

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