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

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

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

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

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

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

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

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

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

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

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

]