Александр Гoлдун
Если есть один пример, где это неприменимо, то это еще ничего не значит.
В компьютерной фирме я могу купить HDD, а могу и комп, включающий в себя
этот HDD.
Никто и не возражает. Мало того, в моей схеме это делается абсолютно естественно. В то же время в комьютерной фирме Вы вряд ли сумеете купить одиночный винтик - максимум "комплект" (если это не нормальная фирма, где скажут - "вон, отсыпь из коробки").

Ситуаций, когда "может быть куплено все", пожалуй не существует. Вряд ли директор согласится продать свой личный письменный стол - а вот в классификатор он может попасть, для нужд учета.

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

Александр Гoлдун
И что в результате получим? В двух таблицах записи, соответствующие
одной и той же сущности?
Почему одной и той же?

Что есть "одна сущность", а что есть "разные сущности" - вопрос религиозный. Скажем, "документ", "накладная" и "счет" - это одна сущность? Две? Три?

Александр Гoлдун
И про какие нормальные формы ты говоришь после этого?
Кстати, во многих изложениях нормальных форм этот пункт никак не регламентируется :) Существуют два варианта: либо стартуем из одной таблицы, содержащей всю БД (и тогда такого не получится), либо просто формулируем требования первой нормальной формы - и тогда дублирование записей между таблицами формально ничему не противоречит.

Александр Гoлдун
Как должна выглядеть в БД элементарнейшая накладная на внутреннее
перемещение, в которой может быть сырье, комплектующие, полуфабрикаты и
готовая?
Зависит от структуры базы. Отметим, что "продажные" характеристики товара никак не зависят от внутреннего перемещения, поэтому структура, которая потребует затрагивать их при этой операции будет несколько нелогичной.

Александр Гoлдун
> коллизии, когда кто-то ошибся и выписал клиенту непродаваемый полуфабрикат.
А в чем трабл? Какие коллизии?
Такие коллизии. Когда продавец промахнулся, прошла оплата, клиент с накладной приехал за товаром - а товар не может быть отпущен, в силу, например, того самого "не на том счету". Ситуация не может быть оперативно исправлена, например, из-за другой цены "правильного" товара, нужно разбираться как с бумажками - чтобы все правильно было оформлено, так и с программой - откатывать оплату счета, редактировать счет..

Александр Гoлдун
> По-хорошему - это нарушение второй, кажется, нормальной формы (станет
> нарушением, как только появится поле, проставляемое только для "готовых"
> изделий и всегда пустое для комплектующих).
Например?
"Розничная цена".

Александр Гoлдун
Можно решить и при помощи FK, если уж припрет. Причем не так уж сложно.
Тупейший пример - составной FK по полям код изделия и тип изделия,
причем на тип в счете ставится check constraint.
Можно. Но криво. А необходимость кривых решений лично меня заставляет усомниться в предпосылках этих решений. По моему опыту, есть две типовых ситуации разработки:

1. Делаешь "как надо". Держишься в накатанном, предусмотренном теорией и проверенном практикой русле. Проблем не возникает - все давно выверено.

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

Есть, конечно, третий тип, в принципе допустимый - "локальная кривизна, которая ни на что серьезно не влияет". Но - чтобы не допустить второго варианта - лучше избегать и этого.

Александр Гoлдун
А зачем? Есть множество
корректных и удобных способов обеспечения целостности и
непротиворечивости данных. FK - лишь один из них.
Не только "лишь один", но лучший по "универсальность+стоимость+качество". Тем более, для учетной задачи, для которой характерна довольно быстро меняющаяся бизнес-логика.

Александр Гoлдун
Кроме того может быть компромиссный вариант с использованием
наследования. Например базовая сущность - изделие. Отдельная таблица.
Дочерние сущности - комплектующие, готовые, сырье и т.п. можно разнести
по разным таблицам, обеспечив связку по PK с изделиями. Такой вариант
применим в большинстве случаев, т.к. обеспечивает и удобство
объединения, и преимущества жесткого разделения там, где надо.
А, собственно, практически это я и предлагаю, если Вы не заметили

Единственно, я не очень люблю связку по первичным ключам - как-то так складывается, что именно ее потом часто приходится переделывать.

Posted via ActualForum NNTP Server 1.1[/quot]

Andres 1Почему? Так и представляю себе ситуацию - покупается новый стол, а старый так аккуратненько в загашник - а вдруг пригодится?
Вот когда "а вдруг пригодится" - тогда и появится строчка в прайсе "стол директорский". А пока он стоит в кабинете - рискну предположить, никто столько не заплатит.