Плюсы / минусы и способы реализации глобального уникального идентификатора в реляционной базе данных?

Question

Относительно первой части моего вопроса: я недавно спрашивал себя, каковы преимущества и недостатки наличия уникального идентификатора для определенных таблиц в реляционной базе данных.В качестве примера API-интерфейс Facebook (FB) Graph позволяет извлекать различные типы объектов, такие как «Пользователи», «События», «Страницы» и т. Д., Используя один и тот же URL, например, https://domain/251906384206 возвращает объекттипа «Событие», тогда как https://domain/195466193802264 возвращает объект типа «Группа».

В чем преимущество этого подхода по сравнению с предоставлением менее "универсального" API, который будет использоваться следующим образом: https://domain/event/251906384206 или https://domain/group/195466193802264. В этом случаеПодобный идентификатор может использоваться для разных типов объектов, поскольку каждый тип объекта имеет свою область идентификатора.

Относительно второй части вопроса: каковы варианты реализации глобального уникального идентификатора?

Мне на ум приходят два варианта:

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

2. Предоставление таблицы с 3 столбцами, содержащей

   • уникальный идентификатор,
   • тип объекта Specc Primarключ и
   • имя таблицы.

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

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

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

Answer 1

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

У меня такое ощущение, что было бы лучше применять глобальные идентификаторы на уровне доступа к приложениям / данным.Это можно сделать тривиально, следя за тем, чтобы идентификаторы для каждого конкретного типа объектов исходили только из подмножества возможных идентификаторов.Например, вы можете зарезервировать последние / первые x битов всех идентификаторов, чтобы указать тип объекта.Оставшаяся часть идентификаторов будет «фактическим идентификатором».

Если вы боитесь ошибок при назначении идентификаторов для специальной таблицы, вы можете добавить проверочное ограничение, которое обеспечит правильность идентификатора (например, идентификатор <4000 И ID> 10000).Если вас беспокоят потери битов / байтов для типа объекта в его идентификаторе, вы можете предоставить глобальный идентификатор только в своем API доступа к базе данных, который объединит идентификатор объектов (фактически хранящийся в таблице) с их идентификаторами типов (происходит от типа объекта).

Answer 2

«Хорошо сформулированная проблема - это проблема, которая уже наполовину решена».

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

У вас есть несколько объектов разных классов, и вы хотите знать, как хранить их в базе данных. Обычно это называется «причудливым именем» реляционного сопоставления объектов (O.R.M.).

Кроме того, вы хотите использовать глобальный уникальный идентификатор (G.U.I.D.), чтобы идентифицировать объект как бизнес-объект / объект программирования и строку в таблице.

Кроме того, вы также хотите использовать G.U.I.D. идентифицировать класс или объект определенного типа.

Допустим, вы создаете приложение. где у вас есть несколько объектов. Существует несколько классов объектов, таких как «Пользователи», «События», «Страницы» и другие. Вы можете иметь несколько объектов одного и того же класса / типа, но вам нужен способ отличить один от другого. Для идентификации «Джона Доу» из Мичигана, из «Джона Доу» из Квинсленда. Допустим, ваши объекты будут использовать свойство типа G.U.I.D.

Итак, давайте предположим, что вы создали таблицу для каждого класса («user» для «Users», стандартный идентификатор таблицы - единственное и строчное, хотя вы можете игнорировать ее, «event» для «events» и т. Д.). Каждая таблица имеет несколько полей, которые представляют свойства каждого объекта. Таким образом, «пользователь» будет иметь такие поля, как «user_key GUID» и, возможно, «user_name varchar (100)» и «user_birthdate datetime». То же самое относится и к другим таблицам.

Я использовал «supertable», но только для очень специфических, не распространенных приложений. Я не думаю, что вам нужна таблица, которая смешивает "пользователи", "события", "страницы". У меня был случай, когда у нас были супертаблицы «клиенты», а также подтаблицы «компания» и «человек» с конкретными дополнительными полями. Иногда нам приходилось проверять продажи для всех клиентов и объединять их с помощью таблицы «клиенты». Иногда нам приходилось предлагать корпоративную скидку на продукты и просматривать подтаблицу «компания».

В случае, если вы хотите, чтобы этот Supertable / «IS a» был супертабильным, вам не нужно иметь другое поле для первичного ключа суперпопулярного первичного ключа и таблицы сведений, может быть одного типа.

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

Г.У.И.Д. использует больше памяти и дискового пространства, чем целочисленный ключ, но очень быстро и легко получить ключ, который очень сложно скопировать.

Опять же, вы спрашиваете больше о том, как представлять объекты в базе данных, чем об использовании G.U.I.D.