powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как сделать структуру базы для хранения важности заявки
25 сообщений из 81, страница 3 из 4
Как сделать структуру базы для хранения важности заявки
    #34784754
просто бык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
beluginА как предполагается использовать историю важности? С некотороми заявками случаются преинтереснейшие истории - несомненно есть что почитать...
А чем так плохо (если важности как я не влияют на цены)?
Заявки (Заявка_ИД PK)
Заявленные_товары (Заявленный_товар_ИД PK, ЗаявкаИД FK)
История_важности _заявленных_товаров (ИД PK, Заявленный_товар_ИД FK, Дата, Важность)
Потом вьюхой просто выбрать последнюю дату важности.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34784912
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
beluginА как предполагается использовать историю важности? Кто будет ее смотреть и с какой целью?

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

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

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

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

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

Использовать для отчетности в основном. Например хотят посмотреть какой был план заявок в феврале, и как он выполнялся. Соответсвенно с информацией актуальной на февраль
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34784941
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
просто бык beluginА как предполагается использовать историю важности? С некотороми заявками случаются преинтереснейшие истории - несомненно есть что почитать...
А чем так плохо (если важности как я не влияют на цены)?
Заявки (Заявка_ИД PK)
Заявленные_товары (Заявленный_товар_ИД PK, ЗаявкаИД FK)
История_важности _заявленных_товаров (ИД PK, Заявленный_товар_ИД FK, Дата, Важность)
Потом вьюхой просто выбрать последнюю дату важности.

Это хорошо!
А где количество? Над которым мы с Владимир П. бъемся?
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34784946
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BULK INSERTну так сядь, отдохни и не напрягайся...

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

Все нормально...
Давайте продолжим обсуждение
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785002
Нет количества. Фиг вам, а не количество. Это у вашего поставщика может быть количество, продаст вам всё соотвествеено вашей заявке и выпишет общий инвойс 4 харда по 120 рублей, 20 вентиляторов по 150 руб.
А заявках количество не должо быть делимо - 1 харб для бухалтерии компа Нр 1, 1 хард для бухалтерии компа Нр 2, 2 харда для сервера (для райда, и идут они всегда парой, недилимы).
Што это за заявка 4 харда? Каму, куда, зачем? Это только в отчётах/запрсах надо выводить - всего заказано 4 харда (например).
ЗЫ - вам уже говорили, сначала определитесь с документацией, а потом свой бардак компутеризируйте. Щас у вас что заявку ножницами разрезают на части, когда важность меняется?
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785025
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все же сначала бизнес-процесс.

Тем или иным путем значение заявитель изменил заявку З.
Имеем З(позавчера) != З(вчера).
Снабженц была выполнил З(вчера) но провалил З(позавчера), в результате заявитель также что-то там не выполнил.

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

Без этого бессмысленно говорить о структурах - да меняйте заявители как хотите, а снабженец иногда возможно прочитает, и никто, ничего, ни с чем сравнивать не будет.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785042
koromuslo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Во первых определитесь со списком сущностей и их атрибутов, а также с характером связей между ними. Ну например:
Заявка(Номер, Дата_создания, ...),
Строка_заявки(Название_товара, кол-во),
Важность(Дата_установки, Значение_важности).

Связи:
Заявка<->>Строка_заявки (связь один ко многим)
Строка_заявки<->>Важность (связь один ко многим)

Исходя из этой информации уже проектируешь таблицы:
Заявка(ID, Дата_создания, ...)
Строка_заявки(ID_Строки, ID_Заявки, Товар, Кол-во)
Важность(ID_Строки, Дата_установки, Значение важности, Кол-во)

Разумеется придется контролировать корректность вводимых данных. Правда с таким подходом клиентское приложение несколько усложниться.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785102
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ModelRВсе же сначала бизнес-процесс.

Тем или иным путем значение заявитель изменил заявку З.
Имеем З(позавчера) != З(вчера).
Снабженц была выполнил З(вчера) но провалил З(позавчера), в результате заявитель также что-то там не выполнил.

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

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

Как это меняйте как хотите? Все будет изменяться строго с официальными докмунетами. И сама заявка и ее важность. Кто ввел докумнет - в программе хранится. Все понять очень просто.
К тому же я говорил: важность - это планируемая, конечно фактически порядок приобретения строго никогда не будет соответсвовать планируемому.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785119
То есть заявка - это строгий официальный документ? Ну и что вы с ним сделаете когда кол-во поменятся?
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785129
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
koromusloВо первых определитесь со списком сущностей и их атрибутов, а также с характером связей между ними. Ну например:
Заявка(Номер, Дата_создания, ...),
Строка_заявки(Название_товара, кол-во),
Важность(Дата_установки, Значение_важности).

Связи:
Заявка<->>Строка_заявки (связь один ко многим)
Строка_заявки<->>Важность (связь один ко многим)

Исходя из этой информации уже проектируешь таблицы:
Заявка(ID, Дата_создания, ...)
Строка_заявки(ID_Строки, ID_Заявки, Товар, Кол-во)
Важность(ID_Строки, Дата_установки, Значение важности, Кол-во)

Разумеется придется контролировать корректность вводимых данных. Правда с таким подходом клиентское приложение несколько усложниться.

Придется контролировать чтобы кол-во в таблице Важность не превышало кол-во в строке_заявки
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785143
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
любопытный мумуТо есть заявка - это строгий официальный документ? Ну и что вы с ним сделаете когда кол-во поменятся?

Да не меняется в заявке количество. Меняется важность товаров из заявки. И не в докумнете заявка а каким-нибудь другим документом: план покупок.

А в принципе можно даже поменять и количество в заявке. Но это уже не относится к текущей теме.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785173
точный бык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
es3000каким-нибудь другим документомВот вы тогда всё-таки сядьте, расслабтесь и подумайте о комнить другом документе. Как с ним всё будет ясно, база сама вырисуется.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785258
__John__
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
es3000 любопытный мумуТо есть заявка - это строгий официальный документ? Ну и что вы с ним сделаете когда кол-во поменятся?

Да не меняется в заявке количество. Меняется важность товаров из заявки. И не в докумнете заявка а каким-нибудь другим документом: план покупок.

А в принципе можно даже поменять и количество в заявке. Но это уже не относится к текущей теме.


Если заявка уже отправлена поставщику например, то смысла менять количество товаров в ней нету
а приоритет для каждого товара отдельно можно хранить.
Например в таблице-заявке на каждую позицию товара с количеством хранить записи вида количество - статус, таким образом в одной таблице например
код заявки товар количество
1000 диск 16х 5

таблица приоритетов

код заявки количество приоритет
1000 2 4
1000 3 5
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785553
Фотография BULK INSERT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
__John__Если заявка уже отправлена поставщику например, то смысла менять количество товаров в ней нету

почему это... мы каждый день так делаем
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785555
Не согласен. Заказчику нет смысла менять - мы как поставщики сами поменям ещё лучше чем заказчик
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785565
Фотография BULK INSERT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бые поставщик Не согласен.

хорош уже бухать, отдохни, возьми тайм-аут...
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785571
Фотография бухой бык
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BULK INSERTхорош уже бухать, отдохни, возьми тайм-аут...Такое предложение в тяпницу вечером заставляет задуматься о скверности Вашего характера
после гадкого мартеля, попробовав плиску, никак не могу остановиться
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785596
Фотография BULK INSERT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
бухой быкникак не могу остановиться

да я не со зла слегка из зависти мобыть...

да и авторам дискуссии потом обидно будет от такого количества оффтопега
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34785789
rmmr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Может быть не совсем уместно здесь об этом говорить, но есть вопрос - это всё реально нужно или это чья-то прихоть на предмет наличия фичи?
Если отойти от программирования, то снабженец этой фигнёй париться не будет.
Если только количество заказов не измеряется сотнями, а срок доставки достаточно велик.
Полученный эффект от добавления этой фичи может не оправдать затрат на её добавление.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34787654
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
es3000 ModelRВсе же сначала бизнес-процесс.

Тем или иным путем значение заявитель изменил заявку З.
Имеем З(позавчера) != З(вчера).
Снабженц была выполнил З(вчера) но провалил З(позавчера), в результате заявитель также что-то там не выполнил.

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

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

Как это меняйте как хотите? Все будет изменяться строго с официальными докмунетами. И сама заявка и ее важность. Кто ввел докумнет - в программе хранится. Все понять очень просто.
К тому же я говорил: важность - это планируемая, конечно фактически порядок приобретения строго никогда не будет соответсвовать планируемому.Этого недостаточно. Должна быть формальная процедура вычисления безобразий и их виновников. Иначе будет как с некоторыми российскими законами - написано красиво, но не работает...
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34787890
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
rmmrМожет быть не совсем уместно здесь об этом говорить, но есть вопрос - это всё реально нужно или это чья-то прихоть на предмет наличия фичи?
Если отойти от программирования, то снабженец этой фигнёй париться не будет.
Если только количество заказов не измеряется сотнями, а срок доставки достаточно велик.
Полученный эффект от добавления этой фичи может не оправдать затрат на её добавление.

Ну у нас считают что это реально нужно. Попробуйте просто в Excel-е сделать план покупок хотя бы строк на 50, и переставить местами в соответсвии с изменением приоритета. И делать это ежедневно. На основании приоритета проставляется срок каждой покупки. Даже если одна строка переместилась выше, сроки и важности всех других нижележащих строк меняются. Это все надо переделать вручную. Возможны ошибки, перепечатки и т.д. и т.п. Простая механическая работа, простой алгоритм, почему бы не автоматизировтаь?
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34787897
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
__John__Если заявка уже отправлена поставщику например, то смысла менять количество товаров в ней нету

Отправленные заявки - это заказы. У нас это разные докумнеты: заявка и заказ. Заказ составляется на основании заявок. Заказы меняться не будут. Меняется заявка - это внутрениий докмунет организации, ни кому не отправляется.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34787983
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
es3000 Cane Cat FisherЯ не могу понять одного: представим, что нет ни баз данных, ни компьютеров. Только бумаги. Сформирована заявка на 5 дисков, важность низкая. Подписана, отдана. Потом полетел винт, и один диск стал нужен срочно. Каков документооборот в этом случае?

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

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

Ну вот, в Вашем документообороте наклевываются такие новые понятия:

- Коррекция поданной заявки.

- "Произвольный вид" - если это так, то для автоматизации этого процесса базы данных не нужны, достаточно ксерокса ;-) Думаю, что документ придется все же формализовать - дата, номер заявки, позиции, новые значения (добавить, убавить, изменить).

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

Короче говоря, категорически рекомендую проговорить документооборот без компьютеров, в максимально общем виде, самые немыслимые варианты (типа подана ошибочная заявка, подписана, но не включена в план - операция отмены заявки). Без этого все обсуждение и все структуры смысла не имеют.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34788304
sti
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
es3000Ну у нас считают что это реально нужно.
Тут уже неоднократно встречался такой совет: пусть тот, кто считает, что это нужно напишет ТЗ. Если напишет, что сомнительно, тогда вы узнаете в каком виде это нужно и сможете начинать проектировать. А пока, перечитайте топик, вам многие говорят, что задача не формализована и проектировать просто рано.
...
Рейтинг: 0 / 0
Как сделать структуру базы для хранения важности заявки
    #34788515
es3000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Cane Cat Fisher
Ну вот, в Вашем документообороте наклевываются такие новые понятия:

- Коррекция поданной заявки.

Согласен

Cane Cat Fisher
- "Произвольный вид" - если это так, то для автоматизации этого процесса базы данных не нужны, достаточно ксерокса ;-) Думаю, что документ придется все же формализовать - дата, номер заявки, позиции, новые значения (добавить, убавить, изменить).

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

Cane Cat Fisher
- Нарисовался новый документ - "План". Причем имеет значение, включена ли заявка в план. Если да - то коррекция будет относиться уже к следующему плану. Нет - просто корректируется исходная заявка, и включается в текущий план.

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

Cane Cat Fisher
Короче говоря, категорически рекомендую проговорить документооборот без компьютеров, в максимально общем виде, самые немыслимые варианты (типа подана ошибочная заявка, подписана, но не включена в план - операция отмены заявки). Без этого все обсуждение и все структуры смысла не имеют.
В общем-то все возможные варианты уже перечислены. Может быть остановиться на этом?
...
Рейтинг: 0 / 0
25 сообщений из 81, страница 3 из 4
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как сделать структуру базы для хранения важности заявки
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]