Проектирование базы данных

Привет.

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

1. Вопрос по связи.
Есть Материалы, есть Склад, есть МатериалыПоЗаказу. МатериалыПоЗаказу в итоге попадут на склад.
Отношения:
1. Материалы: id, name...
2. МатериалыПоЗаказу: id, material_id, count, ...
3. Склад: id, material_po_zakazu_id, count

Связи:
1. Материалы(id) < - >> МатериалыПоЗаказу(material_id)
2. Склад(material_po_zakazu_id) ? - ? МатериалыПоЗаказу(id)

Вопрос: какой вид у 2 связи? По-идее 1:1, потому что одному МатериалыПоЗаказу(id) будет соответствовать одна запись на Складе. Я правильно понимаю?

2. А не лучше ли будет сделать связь Склад < - > Материалы? Одной записи в Материалах будет соответствовать 0..1 запись на Складе. Как будет лучше и вообще прав ли я?

Возможно, если еще появятся вопросы буду писать в эту тему.

0

Сообщение от cygapb-007 Один из возможных способов обеспечения ссылочной целостности - использование триггеров на изменение данных в этой таблице, которые будут автоматически корректировать таблицу Склад.

у меня триггер используется такой: когда мы добавляем что-то в Склад (insert into Warehouse ...), то срабатывает инструкция, которая проверяет есть ли уже запись с таким material_id и, если есть, то она делает update этой записи, а если нету, то делает insert into как и планировалось.

Сообщение от cygapb-007 Однако проблема в том, что на складе хранятся итоговые данные по материалам из всех заказов, поэтому связать склад по FK с материалами по заказу не получится.

это значит, что Склад должен висеть у меня без связей вообще?

Сообщение от cygapb-007 а так же ссылаться на нее из МатериалыПоЗаказам (другой способ обеспечения ссылочной целостности).

кажется вот это мне нужно. что за способ?

Сообщение от cygapb-007 с использованием триггеров добавляются данные в таблицу материалов по заказу (при этом триггер автоматически корректирует таблицу Склад).

имеется в виду триггер, который при изменении статуса оплаты будет корректировать таблицу Склад? поясните вот этот момент. я так понял, что это должно работать.

0

Сообщение от VladSharikov у меня триггер используется такой: когда мы добавляем что-то в Склад (insert into Warehouse ...), то срабатывает инструкция, которая проверяет есть ли уже запись с таким material_id и, если есть, то она делает update этой записи, а если нету, то делает insert into как и планировалось.

Нет, триггер на таблицу деталей заказов. При добавлении заказа выполнится проверка таблицы Склад: если материал есть на Складе - количество по нему увеличивается на количество из строки заказа, если нет - добавляется в Склад с тем же количеством, что и в строке заказа. При удалении - обратные действия (уменьшить количество или удалить если остается 0)

это значит, что Склад должен висеть у меня без связей вообще?

Не обязательно, он может ссылаться на Материалы

кажется вот это мне нужно. что за способ?

Это то, что получилось сейчас - сначала занести на склад, и только потом в заказы - то есть неправильно

имеется в виду триггер, который при изменении статуса оплаты будет корректировать таблицу Склад? поясните вот этот момент. я так понял, что это должно работать.

А, забыл, на склад должно попадать по факту оплаты...
Тогда нужен только триггер на UPDATE, в котором при изменении статуса (deleted.status<>inserted.status) либо увеличивается, либо уменьшается количество материала в Склад (как это описано в начале ответа). Возможно, так же понадобится триггер на DELETE (где deleted.status=оплачено).
Хотя, может быть и INSERT,если заводится сразу оплаченный заказ...

Итого получается
- Материалы: РК(id)
- Склад: РК(material_id); FK(material_id)on Материалы(id)
- МатериалыПоЗаказу: РК(order_id,material_id), FK(material_id)on Материалы(id)
- триггер(ы) on МатериалыПоЗаказу after (insert,)update(,delete)

Добавлено через 2 минуты
Триггер на Склад, получается, не нужен, потому что вручную Склад обновлять уже не нужно

1

Сообщение от cygapb-007 Не обязательно, он может ссылаться на Материалы

какая тогда будет связь и по какому полю?
если склад(material_id - unique) М - 1 Материалы (id - primary), то связь по идее сделается 1 к 1? работаю в mssql.

Сообщение от cygapb-007 - Материалы: РК(id) - Склад: РК(material_id); FK(material_id)on Материалы(id) - МатериалыПоЗаказу: РК(order_id,material_id), FK(material_id)on Материалы(id)

вот это я понимаю. единственное. хочу уточнить. зачем делать составной PK (order_id, material_id)? у меня есть просто id в этой таблице, автоинкрементный. он PK.
зачем нужен триггер в упор не понимаю?

p.s.: я уже колебался, думал на счет связи Склад: РК(material_id); FK(material_id)on Материалы(id)

0

Сообщение от VladSharikov какая тогда будет связь и по какому полю? если склад(material_id - unique) М - 1 Материалы (id - primary), то связь по идее сделается 1 к 1? работаю в mssql.

Склад - это подмножество из Материалы, поэтому связь будет Материалы<->Склад (1-0..1), то есть первичная таблица - Материалы, от Склад FK(material_id) on Материалы(ID)

вот это я понимаю. единственное. хочу уточнить. зачем делать составной PK (order_id, material_id)? у меня есть просто id в этой таблице, автоинкрементный. он PK. зачем нужен триггер в упор не понимаю?

ID тут «ни о чем», все равно где-то за кадром таблица счетов - для нее ID нужен, а при вводе деталей ID уже известен, да и материал тоже. РК заблокирует ввод одного и того же материала в рамках одного счета, а ID ничего такого не сумеет.

p.s.: я уже колебался, думал на счет связи Склад: РК(material_id); FK(material_id)on Материалы(id)

В общем-то связь необязательная, если вся обработка Склад будет убрана в триггеры. Недопустимые материалы будут отвергнуты при insert into МатериалыПоЗаказу при помощи FK, а в Склад материалы будут попадать только из строк деталей заказа.

1

cygapb-007, Спасибо, буду думать.

0