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

Что касается первой части моего вопроса: недавно я спрашивал себя, Каковы преимущества и компромиссов, иметь уникальный идентификатор для определенной таблицы в реляционной базе данных. Так же, как пример, Facebook (FB) Graph API позволяет извлекать различные типы объектов, таких как "пользователи", "события", "страницы" и т.д. используя тот же URL, e.g https://domain/251906384206 возвращает объект типа "Event", тогда как https://domain/195466193802264 возвращает объект типа "группа".

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

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

два варианта, которые приходят мне на ум:

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

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

    • уникальный идентификатор,
    • тип объекта specifc primar key и
    • имя таблицы.

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

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

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

7
database-design primary-key relational-database unique-key uniqueidentifier

2 ответов

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

У меня такое чувство, что было бы лучше применять глобальные идентификаторы на уровне приложения/доступа к данным. Это можно сделать тривиально, применяя, что идентификаторы для каждого конкретного типа объекта поступают только из подмножества возможных идентификаторов. Ты мог бы, потому что экземпляр, зарезервируйте последний / первый X бит всех идентификаторов, чтобы указать тип объекта. Оставшаяся часть идентификаторов будет "фактическим идентификатором".

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

0

"хорошо сформулированная проблема-это проблема, уже наполовину решенная".

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

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

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

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

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

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

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

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

Я предлагаю избегать любой ценой использовать составные / составные ключи ("главный ключ "плюс" другие " поля), использовать один первичный ключ поля. Я также предлагаю назначить ключ G. U. I. D. С помощью программирования, а не в база данных.

G. U. I. D. использует больше памяти и дискового пространства, чем целочисленный ключ, но его очень быстро и легко получить ключ, который очень трудно дублировать.

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

0