Пытался задать этот вопрос и раньше, но так как не получил ответа, выношу отдельным постом. Знаю, что среди вас, уважаемые эксперты, есть отзывчевые люди и надеюсь на помощь или некоторые идеи / замечания по данному вопросу.
Ситуация такая:
Фирма занимается изготовлением жалюзи, каждая жалюзи сначала
1) принимается,
2) потом вводится в базу,
3) подтверждается на производство,
4) изготовляется,
5) отдаётся на склад готовой продукции,
6) отправляется оттуда в салон,
7) монтируется и т.д.
Для простоты скажем, что каждая жалюзи перед тем как оказаться у клиента должно пройти 7 стадий (причём логически отдаваться на производство может только после 3 стадии). Пытался придумать схему - попытка привела к схеме изображённой на картинке. Не даёт покоя следующий момент - на производство жалюзи отдаются 3 раза в сутки каждые 8 часов (для каждой смены), чтобы из базы отобрать жалюзи, которые надо изготовлять приходится пересматривать n*7 записей, что даже приняв милион жалюзи довольно много и тормознуто...
Подскажите, по какой схеме Вы бы делали базу исходя из данной ситуации? Готов описать подробнее, если какой-то момент не до конца ясен. Заранее признателен за любую дельную идею и совет.

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

anjeyможет иметь в один момент времени несколько статусов ?НЕТ

anjeyпочему бы просто не добавить напосредственно в tblOrderBlinds еще одно поле, в котором и будет отмечаться статус ?То есть при создании документа изменения статуса, последний присвоенный статус заносить в то поле? При создании следующего документа изменять на новый?

anjeyпривели по нескольку реальных записей из каждой таблицы, для наглядности...

tblOrders
OrderID OrderNo1АА-1112АА-2223АА-333

tblOrdersBlinds
BlindIDOrderIDName11Жалюзья121Жалюзья231Жалюзья342Жалюзья453Жалюзья563Жалюзья6

tblStatuses
StatusIDStatusNameAllowProduceAllowEdit1Жалюзья подтвепждённа для производстваTrueFalse2Жалюзья на производствеFalseFalse3Производство жалюзьи приосановленоFalseTrue4Жалюзья изготовленаFalseFalse............9Не присвоенFalseTrue

tblStatusHistoryDocuments
StautsHistoryDocumentIDStautsHistoryDocumentNoAssignedstatusDate1Подтверждение заказа 112001.01.012Задание на производство 122001.01.023Изятие из производства 132001.01.034Изятие из производства 232001.01.045Задание на производство 122001.01.056Выдача со склада 142001.01.06

tblStatusHistory
StatusChangeIDBlindIDStatusHistoryDocumentID1112213314415516617128229321042115212621313142415151625171618261936204621562266

Ну и для извлечения статуса (например чтобы вытащить то, что сегодня надо изготовлять) приходится прогонять такой запрос :(

йо-хо-хоможет быть неизвестно количество переходов состояний - RoutineProcessStages...Да, это имеет место уже сейчас. Я привёл просто очень упрощунную схему..

mcureenabЕсли количество сотояний заказа заранее известно, то почему бы не оформить их одной записью."Потому что" - написано выше. Как я понял из сказанного набиолее хороший выход - (цитирую себя)
БыкисТо есть при создании документа изменения статуса, последний присвоенный статус заносить в таблицу жалюзей? При создании следующего документа изменять на новый?Если ничего лучшего нету - переделую на это...

А? То есть мою схему оставляем, но статусы вытягиваем не запросом, а функцией? Будет оперативнее?

Ещё раз уточню для чего всё это. Надо выбирать из таблицы жалюзи те жалюзи, у которых статус AllowProduce = True, то есть из tblStatuses
StatusIDStatusNameAllowProduceAllowEdit 1Жалюзья подтвепждённа для производстваTrueFalse ............ 10Гарантийны ремонтTrueFalse 11Дополнительные работыTrueTrue ............
Как их выбрать, не перебирая все?

Нужна история
ByKiSТо есть мою схему оставляем?И пользуем функцию? Или в схеме можно что-нибудь изменить, для убыстрения ф-ии?

Too few parameters. Unknown syntax near 'помятуя' :)

Подробнее пожалуйста. Я тут о перебирании всех жалюзей, а Вы?

BULK INSERTесли бы вы решали две задачи параллельно ERP и CRM это было бы понятно, но когда вы мешаете все в кучу, понять вас становится слишком сложноА неполучается так вот красиво разделить. Весь этот весь этот мусор нужен для установки виновника при обнаружении брака (кто мерил, кто вводил, кто резал и клеил, кто монтировал и т.д.).

Наряды - это типо моего "tblStatusAssignationHistoryDocuments" ?