Привет.
Краткая суть:

Есть таблица пользователей users.
Есть корневая таблица goods, которую наследуют таблицы: drinks, food, alco ...

Есть таблица rating, в которой первичный ключ представлен двумя полями: user_id из таблицы users и goods_id из корневой таблицы товаров. Также в таблице rating есть поле rating_value, отвечающее за проставленную пользователем оценку.

Предполагается, что каждый товар может быть оценен каждым пользователем 1 раз.


Однако в этом случае, судя по докам, первичный ключ в таблице rating, ссылающийся на ID товара ( goods_id из корневой таблицы goods ), будет применим только для записей корневой таблицы, но не для записей из наследующих таблиц.
Т.е. если пользователь захочет оценить товар, находящийся в наследующих таблицах, он этого сделать не сможет.

http://www.lghost.ru/docs/postgres/postgres/ddl-inherit.html

авторЕсли в другой таблице какая-либо колонка имеет ограничение REFERENCES cities(name), то оно будет работать только с значением name в таблице cities, но не с значением name в таблице capitals. В данном случае — это нехорошо.

Примечательно то, что выборка SELECT распространяется и на дочерние (наследующие) таблицы, а внешний ключ - нет: только на родительскую таблицу.

Существует ли решение, которое позволяет "распространить" проверки первичного ключа на наследующие таблицы? Так же, как в случае с выборкой SELECT? Возможно, это правило Rule или триггер?

Или более понятный пример в этом случае - корзина товаров, состоящая из полей fkey_user_id (кто положил товар в корзину ) и fkey_goods_id (какой именно товар). Если сделать запрос SELECT fkey_user_id, fkey_goods_id FROM cart, мы получим в ответ только те товары пользователя в его корзине, которые принадлежат корневой таблице goods. А если он набрал товаров в "дочерних" категориях, то в корзине они будут не видны.

Привет. Спасибо за ответы.

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

К такой структуре данных пришел потому, что не нашел подходящего способа решения в mysql:

можно было использовать разреженную таблицу ( sparsed ), но по мне хранение всех параметров всех категорий товаров в одной таблице - дурной тон.. Атомарность данных, нормализация БД нарушаются..
можно было использовать хранение свойств товаров в JSON-сериализованных данных, но этот вариант мне тоже не подошел, потому что по свойствам надо работать, делать выборки и пр.
можно было использовать паттерн EAV, но мне он не понравился по ряду причин, в числе которых трудности с использованием дополнительных таблиц, хранящих значения атрибутов.. И сложность запросов - масса JOIN'ов и прочее..

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


> для goods и всех наследников должны быть триггеры before insert,update,delete,truncate синхронизирующие goods_id c goods_shadow_pk.goods_id, кроме того нужен триггер на drop таблицы наследника goods, как-то так....

Удаление не потребуется, поскольку товар, единожды принимавший участие в расчетах (например, был заказан), останется в БД.
Удаление таблиц тем более.. Речь иет о небольшом заведении типа кафе или ресторанчика, миллионные записи в таблицах очень нескоро будут достигнуты.. )


> (хотя изначально у вас архитектура хромая, если товаров добавлено в соседней категории, то пользователь все равно должен их увидеть в своей карзине)
Ага. На первый взгляд, может, и хромая. Но куда более хромые варианты перечислены выше в этом же сообщении).
Буду рад услышать предложенные варианты улучшения архитектуры. Про деревья почитаю, подумаю, как их увязать с предполагаемой архитектурой БД.

Вариант с наследованием таблиц оказался бесполезным в рамках данной задачи..
Внешний ключ, использующий ID товара из корневой таблицы, не работает с товарами из дочерних таблиц..

ERROR: insert or update on table "cart" violates foreign key constraint "fkey_goods_id"
DETAIL: Key (fkey_goods_id)=(6) is not present in table "Goods".
SQL state: 23503