Владимир П.
Просто столбец таблицы. Почему не устраивает такое решение? Что важность может меняться? Ну так записи ведь редактируемые; а не так: один раз завёл, и всё, капец, больше ничего менять в заявке нельзя.

Менять можно. Но для важности надо хранить историю изменений.

Владимир П.
В таком случае вы сами себе -- причём организационно, а не технически -- заблокировали возможность вносить правки в заявки. Тут уж проблема делопроизводства, а не проектирования структуры.

Это вообще нормальная практика, когда докумнеты прошлых периодов запрещены на редактирование. А при необходимости их изменений делаются всякие там сторно и т.д. Как счета-фактуры.
А в моей задаче изменение требуется вносить не в саму заявку, а в ее важность. Важность вообще в заявке при первоначальном вводе можно не указывать. А вводить отдельным докумнетом. Типа "установка приоритетов закупок" или "утверждение плана закупок".

Владимир П.
И почему в закрытый период попала неисполненная заявка?

А почему бы и нет? Два месяца назад сделали заявку. Важность у нее очень низкая - необходимо приобрести товар в течение года. И прошлый период закрыли. Никакого криминала.

Владимир П. Очень плохо. Чем по сути исходные заявки отличаются от расщеплённых? Ничем: и то, и то -- завки. Поэтому быть им в одной таблице.
Историю и взаимоотношение заявок можно организовать через дополнительное поле -- назовите его "Основание" или "Предыдущая версия заявки". Это поле -- ссылка на другую запись в этой же таблице (древовидная структура). Если NULL -- это первоначальная заявка. Если номер заявки -- значит заявка с этим самым номером есть предыдущая версия данной заявки.

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

му-му
начали вы с "важность заявки", а кончили "важность заказанного товара"... За срочность - нет никакой наценки? То есть если сделали простую заявку на 5 HDD по 100$ и её "закрыли", а потом передумали и решили, что один надо срочно, пусть и за 120$, задним числом менять плановую стоимость заявки?
А если стоимость не меняется - просто добавте "желаемая дата поставки" в таблице заказанных товаров...

Ну да. Получается что общая постановка задачи немного уточняется. Про изменение плановой стоимости - не думали. Да вообще пока в поставленной задаче для заявок цены не имеют значения.
Про изменение жедаемой даты поставки: добавить новое поле в таблицу и его менять - это дело несложное. В общем структуру БД обрисуйте. Заявки, заявленные товары, желаемая дата поставки (с учетом истории изменения). Чтобы между ними были связи.

мод
Будет новая заявка:
2 диска важность "срочно" на замену заявки "от 6.09.2007"

А про 3 диска где будет запись?
А если потом еще раз поменчется важность? Например на 4 диска поставим важность "срочно", а на оставшийся 1 важность "не очень срочно"? И потом понадобится определить текущую важность товаров, вы представляете как этот отчет собрать? Пересчитывать все движения: 5 = 3 + 2 = 4 + 1?

belugin
Когда я занимался подобной штукой, у нас было так (может каких деталей и не упомню но общий дух такой):
*после создания заявки она утвердалась (был набор галочек)
*утвержденные заявки просматривались работником отдела закупок, по ним формировалась закупка в результате чего возникали записи о сопоставлении заявок и закупок
*по мере разноски закупок строки заявки считались выполненными

Таким образом у строк заявки был свой жизненный цикл отличный от заявки в целом

По поводу приоритета. Можно сделать так: добавить в строку заявки поле "приоритет" типа float и сделать интерфейс где будет список незакрытых заявок и кнопки "вверх" и "вниз". При нажатии на "вверх" у выделенных строк будет меняться приоритет так, чтобы они встали перед предыдузей строкой; "вниз" - аналогично.

Да у меня проблема-то не в том как интерфейс сделать. И по сопоставлении закупок с заявками тоже не стоит вопрос. Проблема разработать структуру базы, чтобы можно было хранить требуемые мне данные: заявки, товары по этим заявкам, количество и важность. Причем важность должна храниться с историей изменения. Причем на часть заявленного товара может быть одна важность, а на остаток - другая. Вот и все. Одной таблицей заявок тут не обойтись. А интерфейс потом нарисуем...

Cane Cat FisherЯ не могу понять одного: представим, что нет ни баз данных, ни компьютеров. Только бумаги. Сформирована заявка на 5 дисков, важность низкая. Подписана, отдана. Потом полетел винт, и один диск стал нужен срочно. Каков документооборот в этом случае?

Интересный вопрос. Щас подумаем

Cane Cat FisherЯ не могу понять одного: представим, что нет ни баз данных, ни компьютеров. Только бумаги. Сформирована заявка на 5 дисков, важность низкая. Подписана, отдана. Потом полетел винт, и один диск стал нужен срочно. Каков документооборот в этом случае?

Например, в произволном виде пишем служебную записку: "просим приобрести 1 диск по заявке №111 очень срочно всвязи с выходом из строя!"
Важность может быть не связана с заявкой и может устанавливаться отдельным документом.

При составленнтии новго плана закупок эта важность учтется.

Владимир П. es3000Менять можно. Но для важности надо хранить историю изменений.

es3000А про 3 диска где будет запись?
Или поправлена исходная заявка. Или в новой заявке, вот так:

В последнем случае, поскольку для заявки № 1 сущесвуют порожденные заявки, № 1 считается недействующей.

А если опять меняется важность? Например 1 диск нужен срочно, а 4 - не очень. Какие добавятся запсис в таблицу?

Владимир П. BULK INSERT
тремя как минимум (вообще 4-мя)
сама заявка
строка заявки
степень срочности
история изменений

Нет, максимум двумя.

1. Сама заявка.
Строки заявки -- нет такого понятия. В одной заявке вещь только одного наименования.
2. История. В зависимости от того, нужна история только важностей или история всей заявки, то и храним. Если храним историю заявок, то важность -- один из атрибутов заявки; он входит в саму заявку, а не в отдельную таблицу.

Вы нигде не учли количество товара и его важность. Посмотрите как в последнем примере. Сначала нужно 5 дисков, потом 2 срочно и 3 не очень, пототм 1 срочно и 4 не очень. Как это вписывается в вашу структуру?

Ошибся :)
Последний ответ для BULK INSERT

Владимир П.
Может в последних двух строках всет-таки сослаться на первый варинат заявки?

proposed amendmentколичество товара и его важность отмечается как раз в строке заявки...

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

Или использовать механизм , который предложил Владимир П.: использовать измененные строки заявки.

stiНе прояснилось. "Работник" это кто? Тот, который создает заявки или тот, который принимает решение о закупке?

По-моему, у вас у самих нет ясного представления, как это должно работать. Практически же ввести более трех ступеней важности нереально, а значит разобъется ваше множество из 10000 единиц на три части. Куча работы, все при деле, а эффекта - ноль.

У меня у самого есть "очередь", которая формируется на основе "важности". Дак там реально более двух ступеней не используется, хотя предусмотрено 5. Дак там хоть все автоматически формируется.

Работник - это общее понятие. Один работник создает заявку, другой ставит ей приоритет, утверждает, тритий выполняет закупки по плану закупок. В принципе для структуры БД неважно кто такой работник. Это организационное понятие.
Насчет количества ступеней важности. Я про количество ступеней ничего не говорил. Пусть будет 5, пусть будет 2, пока не важно. Вообще я это поле планирую сделать числовым. Чем выше число тем выше важность. Будут использовать только два значения - да пожалуйста. Это на суть задачи не влияет