Pull to refresh

Comments 11

Наследование таблиц появилось в Постгресе с версии 9.1 и близко концепции наследования классов.
Только не классов, а таблиц, и не в Руби, а в Постгресе.

Вы ничего не перепутали? Наследование таблиц в PostgreSQL есть с незапамятных времён, ещё когда это был исследовательский проект университета Berkley.
Ага, спасибо за уточнение, обновил информацию.
UFO just landed and posted this here
UFO just landed and posted this here
Там есть ещё проблемы. К примеру: если у Вас в базовой таблице идёт not null поле, а в дочерней Вы хотите убрать это ограничение, то у Вас крупные проблемы. Вы таки его сможете убрать и все будет супер, но только до тех пор, пока Вы не сделаете бекап и не попробуете его развернуть обратно. Оказывается модификация существующих полей, в наследуемых таблицах, не попадает в дамп бекапа! И Вы потеряете ряд данных, т.к. not null, после восстановления структуры, будет сново в строю :(
Это уже похоже не на проблему, а просто на баг.
В mailing list'ы писали?
Думаю не лишним было бы упомянуть о недостатках наследования в PostgreSQL, потому что недостатки эти в некоторых ситуациях могут быть весьма существенными.
К примеру, невозможность установки общих ограничений (например UNIQUE), невозможность использования внешних ключей на всех наследников.

В этом случае лучше применить традиционный Class Table Inheritance, когда у вас есть одна родительская таблица в которой содержатся основные записи, и отдельно таблицы классов, которые ссылаются на главную таблицу и не имеют собственных суррогатных ключей.
Как я понимаю, предлагается jsonb как универсальный формат хранения. Вопрос. Учитывается ли фрагментация данных при изменении? Когда одна запись (об одном объекте) хранится в разных частях физического диска.
Нет, наоборот не рекомендую jsonb в роли универсального формата данных.
Как можно получить коллекцию материалов, в которой Articles, Onlines, NewsItems будут вперемешку, каждый со своими допполями? Очевидно, не Topic.all
Sign up to leave a comment.