registerersКот Матроскинвключаете поле Type в ключ, накладываете на него соответствующие ограничения в каждой из subtype-таблиц
Интересно, как вы себе представляете эти "соответствующие ограничения"?))

Крайне просто - ограничение значения константой.

registerersВот, например, физическая модель, из которой видно, что любая из subtype-таблиц может ссылаться на одну и ту же запись в supertype-таблице:


Тут есть Type в составе ключа Product?

hVosttКот Матроскин,

Cart и Order лучше бы отсадить, так как корзина это то, с чем работает пользователь, а заказ это то, с чем работает отдел продаж и доставки. Заказ может впоследствии отличаться от корзины.
схема не моя, а моего оппонента :) но я, кстати, не разделяю идею "Cart и Order лучше бы отсадить".
Работают разные категории пользователей - ну и что? С таблицей контрагентов может работать десяток разных категорий - ее тоже надо бить на 10 разных таблиц? :)
Заказ может впоследствии отличаться от корзины - опять же, заказ может изменяться (и, следовательно, отличаться от предыдущего состояния) на разных этапах своего существования, и что?

registerersНо тогда возникает вопрос - как обеспечить константность значений полей SubA.Type, SubB.Type,

Ограничениями (check), я же сказал. У разных СУБД механизм отличается, но не сильно.
registerersи как быть с суб-таблицами при удалении соответствующих типов?
Не понял. Вы хотите убить тип "ProductB", но при этом сохранить таблицу ProductB? А какой в этом физический смысл?

registerersКот МатроскинНе понял. Вы хотите убить тип "ProductB", но при этом сохранить таблицу ProductB? А какой в этом физический смысл?
Наоборот, я не хочу сохранять эту таблицу))) В том то и дело, что не существует механизма удалить таблицу автоматически и это нужно делать только в приложении
Не вижу проблем в пустой таблице (очиститься-то она у Вас очистится при ON DELETE CASCADE).
Да, в реляционной модели при очистке родительской таблицы подчиненные таблицы автоматом не дропаются - при удалении всех заказов таблица элементов заказов тоже не дропается, если такое поведение требуется - надо прописывать руками. Если Вы это считаете серьезным недостатком - ну да, РСУБД Вам подходят не очень.

hVosttКот Матроскинсхема не моя, а моего оппонента :) но я, кстати, не разделяю идею "Cart и Order лучше бы отсадить".
Работают разные категории пользователей - ну и что? С таблицей контрагентов может работать десяток разных категорий - ее тоже надо бить на 10 разных таблиц? :)
Заказ может впоследствии отличаться от корзины - опять же, заказ может изменяться (и, следовательно, отличаться от предыдущего состояния) на разных этапах своего существования, и что?

Вот именно, что может изменяться. Поэтому надо разделять. Пользователь редактирует корзину, заказ редактировать не может. Да и циклы разные.
Заказ тоже может изменяться и отличаться от самого себя на вчера - что и с чем Вы будете разделять в этом случае?

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

hVostt Про отличаться от самого себя, это про историю, решается тоже по-разному.

Зачем тогда это приводить как аргумент за "надо разделять", если никакой причинно-следственной связи "может отличаться"->"надо разделять" нет?
hVosttНо поддерживать это будет трудоёмко и, соответственно, дорого.
С чего бы? :)
Наоборот - не надо будет дублировать методы "добавить элемент в заказ", "добавить элемент в корзину", "удалить элемент из заказа", "удалить элемент из корзины", "рассчитать общую стоимость заказа", "рассчитать общую стоимость корзины", ....