Cane Cat Fisher<>
Вторая - в печь.

Джоша Беркус, CEO компании PostgreSQL Experts Inc.Однако иногда разработчики говорят о том, что ключи [первичные] для записи меняться не должны и должны оставаться одинаковыми на всей протяженности жизненного цикла записи. Имейте ввиду, что это утверждение яйца выеденного не стоит и уж, разумеется, полностью отсутствует в реляционной теории.

<>
если подумать, то попытка всегда протаскивать "естественный ключ" в базу - это попытка изначально "денормализовывать" (не денормализовывая) её с тем, чтобы не приходилось потом строить мат-вью по кросс-наборам-полей таблиц и т.п. (и иметь составные индексы по реальным реквизитам предметной области "из разных таблиц", а не по смеси суррогатов и реквизитов) И on update cascade - тут очень даже приемлемая плата (в противном - для той же производительности поиска - надо поддерживать обновляемые мат-вью, с той же проблемой массового апдейта).

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

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

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

так что и в печь рановато, но и принимать на веру всегда - лишнее. думаецца

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

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

Тогда можно как-то понять его высказывание, что ключевые атрибуты записей, скорее всего, будут меняться: люди выходят замуж, отказываются от ИНН по религиозным соображениям, меняют паспорта и т.д.

Но это же говорит о разумности суррогатного ключа?

Короче, дядька что-то имел в виду, но что - непонятно. Без него этот разговор не имеет смысла. Может кто-то его сюда позвать? Пусть бы пояснил. Или где он тусуется?нет, не говорит.

предположим ,что в большинстве выборок (не из мн-ва физ-лиц, а из мн-ва, куда входит первичный ключ физ-лица в качестве ФК или ссылки) участвует "битой строкой" естественный ключ физ-лица, и скажем в устойчивая комбинация этого естественного ключа с каким-то реквизитом этой подчиненной таблицы . Тогда для быстрого поиска при суррогатном ключе нам придется поддерживать еще и мат-вью с вхождением естественного ключа физ-лица, ключа [не важно суррогата или естественного] починенной таблицы, и указанного реквизита подчиненной таблицы, входящего в связанные поиски. В лучшем случае, если позволяет СУБД , это будет Index-Organized Table - т.е. искомый кросс-табличный индекс. И обновление его будет практически столь же медленным , как и обновление ON UPDATE CASCADE при естественном ключе в таблице физлиц (обновить придется столько же строк нашего IOT - мат-вью). Но в случае с мат-вью нам надо поддерживать ещё одну лишнюю сущность (и лишние JOIN-ы с ними). А при естественном ключе - не надо - там всё проще.

хотя, если иметь в виду версионник, и длина записи матвью много меньше длины записи исходной подчиненной таблицы - non-updateble (ON UPDATE RESTRICT) суррогат несомненно выигрывает по размеру новой версии записи - т.е. дисковой операции. и с необходимостью поддержания лишних мат-вью вероятно можно примириться.


-- как видим, соображения не имеют никакого отношения к реляционной алгебре, но к реализации быстрого поиска, индексов[, денормализации - опционально] и т.п. "низким" материям