В программе сейчас есть таблица заявок. Структура следующая: Дата, Товар, Количество.
Теперь хотят добавить в нее важность заявки. Можно было бы просто добавить новую колонку "Важность".

Но проблема в том, что эта важность во-первых может меняться. То есть сегодня мы решили что важнее купить принтер, а завтра что важнее купить жесткий диск. И нужно хранить установленную важность для заявки на определенную дату. Получается нужно делать отдельную таблицу, которая ссылается на таблицу заявок: ДатаУстановкиВажности, ДатаЗаявки, Товар, Важность.

Во-вторых проблема если заявка на 5 единиц, а нам 3 из них нужно очень срочно, (то есть важность высокая), а 2 - не срочно (важность низкая). Получается нужно как то еще и разбивать по количеству. Ну как по количеству связать две таблицы уж совсем не могу придумать!

Хоть что-нибудь посоветуйте!

модВообще-то заявка - это многострочный документ (типа СФ). Соотв. приоритет можно ставить на каждую строку. В вашем примере 5 штук надо разбить на 3+2 и поставить разные приоритеты. Историю изменений можно хранить отдельно (а можно и не хранить).

Спасибо!
Я так думал сделать, но есть одно но
Заявку мы сделали например неделю назад на 5 дисков, поставили важность среднюю и ждем когда нам привезут, то что мы заказали.
Сегодня у нас вылетел диск, нам срочно его нужно заменить. Не полезем же мы в старую заявку разбивать ее на две строки, изменять приоритет и т.д.
Удобнее было бы как-то сразу указать, что с сегодняшней даты 1 диск нам нужен очень срочно, а остальные - важность не меняется.
Как это можно сделать?

Да в общем-то пока не по каким.

По отделу, например.
Например отделу кадров нужен новый принтер. Мы делаем документ "Заявка", и в нем строка: Отдел кадров, принтер, 1 шт. В принципе можно добавить еще одну строку, например: Бухгалтерия, мышка, 2 шт.

Но это все можно переделать при необходимости. Если придумать удобный механизм для важности. Так что предлагайте любые варианты

ModelR[Посмотрите и с другой стороны: снабженец, закупающий диски уже получил счет от поставщика на 5 дисков и возможно его уже оплатили, а диски в пути и что ему делать?
Возможно вам придется офрмить отдельный заказ на шестой диск.

А как раз и ничего не надо делать. Он видит что по заявке такой то изменилась важность. То есть надо быстрее получить диск. Но диски то уже оплачены и в пути, значит снова заказывать, оплачивать не надо, надо просто поторопить доставку.

модесли не хотите трогать старую заявку (что м.б. и правильно) то надо вводить новую заявку как замену (возможно частичную) старой, т.е. в строке новой заявки сослаться на строку старой заявки типа добавить, заменить, удалить.

Как будет выглядеть струткура таблиц в таком варианте?

ModelRВряд ли доставка сумеет так извернутся, чтобы выдернуть из посылки один диск и доставить на з дня раньше четырех.
А это означает, что начиная с какого-то момента (процесс пошел), статус можно менять только у документа в целом.

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

То есть задачу можно переформулировать так: для заявки нужно хранить планируемую важность. Причем эта важность может изменяться. Нужно хранить историю изменения важности. Какую структуру таблиц использовать для хранения этой важности?

модВ строке заявки два поля: id другой заявки и тип замены (оба м.б. null). Если у вас можно сделать заявки однострочными, то структура будет проще.
А какие данные надо записать в таблицы, чтобы отобразить ситуацию с изменением важности:
1. вчера создаем заявку на 5 дисков
2. устанавливаем важность на сегодняшнюю дату к примеру "не очень срочно"
3. завтра решили для 2 дисков установить важность "срочно", а для 3 дисков оставить прежнюю срочность.

В таблице заявок понятное дело будет только одна запись: 6.09.2007 Диск 5 шт.
А что будет в другой таблице?

Владимир П.Надо отделить заявку от заказа -- это два разных документа.

Заявка пусть будет однострочным элементом. Не по структуре "шапка документа--пункты документа", а только пункты. Одна заявка -- одна вещь. В заявке колонка "Важность", возможно, с хранением истории важностей.
Насчет разделения заявки и заказа - согласен.
А про одна заявка - одна вещь - не понял. Если есть заявка на 5 дисков то что? Делать 5 отдельных строк? То есть 5 отдельных заявок? А если нужно сделать заявку на 1000 единиц?

stiЧестно говоря, так и не понял смысла введения вашей "Важности".

Смысл в удобстве работников отдела снабжения и планирования. Есть 1000 заявок в общей сложности на 10000 единиц товаров и на сумму 1.000.000 руб. Купить все сразу невозможно. Возникает вопрос что купить в первую очередь? Распределить покупки по времени например в течение 3 месяцев. Для этого и нужна важность. Работник формирует список всех заявленных товаров , отсортировав его по важности. Потом обсуждает с заявителями (обычно это начальники других отделов) установленную ими важность, возможно ее корректирует, формирует окончательный список. Отбирает верхние например 10 позиций и начинает закупать. Через неделю процесс повторяется.

Вот. Механизм работы такой, а вот структура БД неясна :(

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

Дополнительное поле дата можно ввести, но ее смысл такой же как и для важности. Чем раньше дата тем важнее. Суть та же, но проблема остается: какую структуру БД сделать для этой даты?

Владимир П.Для удобства в прикладной программе предусмотреть автоматизированное расщепление заявки.

Не-е-е. Заявку расщеплять нельзя. Это документ, он уже сформирован, подписан, и находится в закрытом периоде. Может быть просто сделать доптаблицу, в которой хранить расщепленные заявки? Тогда получается нужно иметь следующие таблицы:

1. Заявки (первоначальный ввод): дата, товар, кол-во
2. Расщепленные заявки: дата, товар, частичное кол-во, важность

Получается надо самому всегда отслеживать чтобы общее количество в расщепленных заявках соответсвовало количеству в первоначальных заявках. Как такой вариант?

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

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

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

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

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

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

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

beluginА как предполагается использовать историю важности? Кто будет ее смотреть и с какой целью?

В моем случае была не одна таблица, а две - заявка и строки заявки.

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

В строке был код номеклатуры, единицы измерения, количество, количество исходное (в случае, если заявку урезали они отличались)

Мне кажется, стоит сделать так: при изменении важности создавать новую заявку с измененными строками, в ней ссылаться на прежнюю заявку (и ее строки, если надо). А измененные строки старой заявки помечать как неактивные.

То есть добавляется новый подвид заявки "Изменение важности", жизненный цикл которой можно отслеживать так же как и у обычной заявки.

Использовать для отчетности в основном. Например хотят посмотреть какой был план заявок в феврале, и как он выполнялся. Соответсвенно с информацией актуальной на февраль

просто бык beluginА как предполагается использовать историю важности? С некотороми заявками случаются преинтереснейшие истории - несомненно есть что почитать...
А чем так плохо (если важности как я не влияют на цены)?
Заявки (Заявка_ИД PK)
Заявленные_товары (Заявленный_товар_ИД PK, ЗаявкаИД FK)
История_важности _заявленных_товаров (ИД PK, Заявленный_товар_ИД FK, Дата, Важность)
Потом вьюхой просто выбрать последнюю дату важности.

Это хорошо!
А где количество? Над которым мы с Владимир П. бъемся?

BULK INSERTну так сядь, отдохни и не напрягайся...

в моем предоложении небыло ничего, что противоречило бы ТЗ... нужно установить важность - устанавливаешь, нужно поменять меняешь.

Все нормально...
Давайте продолжим обсуждение