Хранить в таблице указатели на строки из другой таблицы вместо использования внешних ключей - PullRequest
Новая
       40

Хранить в таблице указатели на строки из другой таблицы вместо использования внешних ключей

1 голос
/ 10 апреля 2011

Мне просто любопытно, можно ли просто использовать указатели c / java / и т.д.способ вместо объединения таблиц на основе внешнего ключа.И поскольку мы обсуждаем эту тему, использует ли postgres или любая другая СУБД указатели при объединении для быстрого поиска строки, на которую ссылается внешний ключ, вместо поиска во всей таблице, содержащей FK?

Ответы [ 2 ]

2 голосов
/ 10 апреля 2011

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

Указатели, конечно же, используются внутри большинства реляционных СУБД на основе SQL.

0 голосов
/ 10 апреля 2011

В Oracle есть нечто, называемое ROWID, которое хранит физический адрес строки в таблице.Они выглядят примерно как AAAA8mAALAAAAQkAAA, который можно разбить на:

  • № объекта данных (сегмент) [AAAA8m]
  • Файл данных в табличном пространстве [AAL]
  • Блок данных (внутри файла данных) [AAAAQk]
  • Строка (внутри блока) [AAA]

Использование rowid - это самый быстрый способ физического нахождения любой строки водин блок чтения.Они используются внутри, но могут быть использованы непосредственно разработчиком.Поиск строки по первичному ключу приводит к одному (или нескольким) чтению индекса, чтобы найти идентификатор строки, а затем база данных найдет блок и извлечет строку.Если кто-то знает идентификатор строки, поиск индекса не требуется.

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

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

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

...