|
|
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
beluginА как предполагается использовать историю важности? С некотороми заявками случаются преинтереснейшие истории - несомненно есть что почитать... А чем так плохо (если важности как я не влияют на цены)? Заявки (Заявка_ИД PK) Заявленные_товары (Заявленный_товар_ИД PK, ЗаявкаИД FK) История_важности _заявленных_товаров (ИД PK, Заявленный_товар_ИД FK, Дата, Важность) Потом вьюхой просто выбрать последнюю дату важности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 15:17 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
beluginА как предполагается использовать историю важности? Кто будет ее смотреть и с какой целью? В моем случае была не одна таблица, а две - заявка и строки заявки. Суть заявки была в том, что объединенные в ней строки вместе утверждались и заявка обладала номером (т.е. с точки зрения пользователя это был аналог бумажного документа). В строке был код номеклатуры, единицы измерения, количество, количество исходное (в случае, если заявку урезали они отличались) Мне кажется, стоит сделать так: при изменении важности создавать новую заявку с измененными строками, в ней ссылаться на прежнюю заявку (и ее строки, если надо). А измененные строки старой заявки помечать как неактивные. То есть добавляется новый подвид заявки "Изменение важности", жизненный цикл которой можно отслеживать так же как и у обычной заявки. Использовать для отчетности в основном. Например хотят посмотреть какой был план заявок в феврале, и как он выполнялся. Соответсвенно с информацией актуальной на февраль ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 15:54 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
просто бык beluginА как предполагается использовать историю важности? С некотороми заявками случаются преинтереснейшие истории - несомненно есть что почитать... А чем так плохо (если важности как я не влияют на цены)? Заявки (Заявка_ИД PK) Заявленные_товары (Заявленный_товар_ИД PK, ЗаявкаИД FK) История_важности _заявленных_товаров (ИД PK, Заявленный_товар_ИД FK, Дата, Важность) Потом вьюхой просто выбрать последнюю дату важности. Это хорошо! А где количество? Над которым мы с Владимир П. бъемся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 15:59 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
BULK INSERTну так сядь, отдохни и не напрягайся... в моем предоложении небыло ничего, что противоречило бы ТЗ... нужно установить важность - устанавливаешь, нужно поменять меняешь. Все нормально... Давайте продолжим обсуждение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:00 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
Нет количества. Фиг вам, а не количество. Это у вашего поставщика может быть количество, продаст вам всё соотвествеено вашей заявке и выпишет общий инвойс 4 харда по 120 рублей, 20 вентиляторов по 150 руб. А заявках количество не должо быть делимо - 1 харб для бухалтерии компа Нр 1, 1 хард для бухалтерии компа Нр 2, 2 харда для сервера (для райда, и идут они всегда парой, недилимы). Што это за заявка 4 харда? Каму, куда, зачем? Это только в отчётах/запрсах надо выводить - всего заказано 4 харда (например). ЗЫ - вам уже говорили, сначала определитесь с документацией, а потом свой бардак компутеризируйте. Щас у вас что заявку ножницами разрезают на части, когда важность меняется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:16 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
Все же сначала бизнес-процесс. Тем или иным путем значение заявитель изменил заявку З. Имеем З(позавчера) != З(вчера). Снабженц была выполнил З(вчера) но провалил З(позавчера), в результате заявитель также что-то там не выполнил. Как параметры позавчера, вчера, сегодня влияют на зарплату заявителя и снабженца ? Кто понять, кто действовал правильно, а кто нет? Без этого бессмысленно говорить о структурах - да меняйте заявители как хотите, а снабженец иногда возможно прочитает, и никто, ничего, ни с чем сравнивать не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:23 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
Во первых определитесь со списком сущностей и их атрибутов, а также с характером связей между ними. Ну например: Заявка(Номер, Дата_создания, ...), Строка_заявки(Название_товара, кол-во), Важность(Дата_установки, Значение_важности). Связи: Заявка<->>Строка_заявки (связь один ко многим) Строка_заявки<->>Важность (связь один ко многим) Исходя из этой информации уже проектируешь таблицы: Заявка(ID, Дата_создания, ...) Строка_заявки(ID_Строки, ID_Заявки, Товар, Кол-во) Важность(ID_Строки, Дата_установки, Значение важности, Кол-во) Разумеется придется контролировать корректность вводимых данных. Правда с таким подходом клиентское приложение несколько усложниться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:26 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
ModelRВсе же сначала бизнес-процесс. Тем или иным путем значение заявитель изменил заявку З. Имеем З(позавчера) != З(вчера). Снабженц была выполнил З(вчера) но провалил З(позавчера), в результате заявитель также что-то там не выполнил. Как параметры позавчера, вчера, сегодня влияют на зарплату заявителя и снабженца ? Кто понять, кто действовал правильно, а кто нет? Без этого бессмысленно говорить о структурах - да меняйте заявители как хотите, а снабженец иногда возможно прочитает, и никто, ничего, ни с чем сравнивать не будет. Как это меняйте как хотите? Все будет изменяться строго с официальными докмунетами. И сама заявка и ее важность. Кто ввел докумнет - в программе хранится. Все понять очень просто. К тому же я говорил: важность - это планируемая, конечно фактически порядок приобретения строго никогда не будет соответсвовать планируемому. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:41 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
То есть заявка - это строгий официальный документ? Ну и что вы с ним сделаете когда кол-во поменятся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:44 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
koromusloВо первых определитесь со списком сущностей и их атрибутов, а также с характером связей между ними. Ну например: Заявка(Номер, Дата_создания, ...), Строка_заявки(Название_товара, кол-во), Важность(Дата_установки, Значение_важности). Связи: Заявка<->>Строка_заявки (связь один ко многим) Строка_заявки<->>Важность (связь один ко многим) Исходя из этой информации уже проектируешь таблицы: Заявка(ID, Дата_создания, ...) Строка_заявки(ID_Строки, ID_Заявки, Товар, Кол-во) Важность(ID_Строки, Дата_установки, Значение важности, Кол-во) Разумеется придется контролировать корректность вводимых данных. Правда с таким подходом клиентское приложение несколько усложниться. Придется контролировать чтобы кол-во в таблице Важность не превышало кол-во в строке_заявки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:46 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
любопытный мумуТо есть заявка - это строгий официальный документ? Ну и что вы с ним сделаете когда кол-во поменятся? Да не меняется в заявке количество. Меняется важность товаров из заявки. И не в докумнете заявка а каким-нибудь другим документом: план покупок. А в принципе можно даже поменять и количество в заявке. Но это уже не относится к текущей теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:49 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
es3000каким-нибудь другим документомВот вы тогда всё-таки сядьте, расслабтесь и подумайте о комнить другом документе. Как с ним всё будет ясно, база сама вырисуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 16:56 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
es3000 любопытный мумуТо есть заявка - это строгий официальный документ? Ну и что вы с ним сделаете когда кол-во поменятся? Да не меняется в заявке количество. Меняется важность товаров из заявки. И не в докумнете заявка а каким-нибудь другим документом: план покупок. А в принципе можно даже поменять и количество в заявке. Но это уже не относится к текущей теме. Если заявка уже отправлена поставщику например, то смысла менять количество товаров в ней нету а приоритет для каждого товара отдельно можно хранить. Например в таблице-заявке на каждую позицию товара с количеством хранить записи вида количество - статус, таким образом в одной таблице например код заявки товар количество 1000 диск 16х 5 таблица приоритетов код заявки количество приоритет 1000 2 4 1000 3 5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 17:20 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
__John__Если заявка уже отправлена поставщику например, то смысла менять количество товаров в ней нету почему это... мы каждый день так делаем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 19:28 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
Не согласен. Заказчику нет смысла менять - мы как поставщики сами поменям ещё лучше чем заказчик ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 19:30 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
Бые поставщик Не согласен. хорош уже бухать, отдохни, возьми тайм-аут... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 19:36 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
BULK INSERTхорош уже бухать, отдохни, возьми тайм-аут...Такое предложение в тяпницу вечером заставляет задуматься о скверности Вашего характера после гадкого мартеля, попробовав плиску, никак не могу остановиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 19:42 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
бухой быкникак не могу остановиться да я не со зла слегка из зависти мобыть... да и авторам дискуссии потом обидно будет от такого количества оффтопега ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2007, 20:03 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
Может быть не совсем уместно здесь об этом говорить, но есть вопрос - это всё реально нужно или это чья-то прихоть на предмет наличия фичи? Если отойти от программирования, то снабженец этой фигнёй париться не будет. Если только количество заказов не измеряется сотнями, а срок доставки достаточно велик. Полученный эффект от добавления этой фичи может не оправдать затрат на её добавление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2007, 01:12 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
es3000 ModelRВсе же сначала бизнес-процесс. Тем или иным путем значение заявитель изменил заявку З. Имеем З(позавчера) != З(вчера). Снабженц была выполнил З(вчера) но провалил З(позавчера), в результате заявитель также что-то там не выполнил. Как параметры позавчера, вчера, сегодня влияют на зарплату заявителя и снабженца ? Кто понять, кто действовал правильно, а кто нет? Без этого бессмысленно говорить о структурах - да меняйте заявители как хотите, а снабженец иногда возможно прочитает, и никто, ничего, ни с чем сравнивать не будет. Как это меняйте как хотите? Все будет изменяться строго с официальными докмунетами. И сама заявка и ее важность. Кто ввел докумнет - в программе хранится. Все понять очень просто. К тому же я говорил: важность - это планируемая, конечно фактически порядок приобретения строго никогда не будет соответсвовать планируемому.Этого недостаточно. Должна быть формальная процедура вычисления безобразий и их виновников. Иначе будет как с некоторыми российскими законами - написано красиво, но не работает... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 11:37 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
rmmrМожет быть не совсем уместно здесь об этом говорить, но есть вопрос - это всё реально нужно или это чья-то прихоть на предмет наличия фичи? Если отойти от программирования, то снабженец этой фигнёй париться не будет. Если только количество заказов не измеряется сотнями, а срок доставки достаточно велик. Полученный эффект от добавления этой фичи может не оправдать затрат на её добавление. Ну у нас считают что это реально нужно. Попробуйте просто в Excel-е сделать план покупок хотя бы строк на 50, и переставить местами в соответсвии с изменением приоритета. И делать это ежедневно. На основании приоритета проставляется срок каждой покупки. Даже если одна строка переместилась выше, сроки и важности всех других нижележащих строк меняются. Это все надо переделать вручную. Возможны ошибки, перепечатки и т.д. и т.п. Простая механическая работа, простой алгоритм, почему бы не автоматизировтаь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 12:29 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
__John__Если заявка уже отправлена поставщику например, то смысла менять количество товаров в ней нету Отправленные заявки - это заказы. У нас это разные докумнеты: заявка и заказ. Заказ составляется на основании заявок. Заказы меняться не будут. Меняется заявка - это внутрениий докмунет организации, ни кому не отправляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 12:31 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
es3000 Cane Cat FisherЯ не могу понять одного: представим, что нет ни баз данных, ни компьютеров. Только бумаги. Сформирована заявка на 5 дисков, важность низкая. Подписана, отдана. Потом полетел винт, и один диск стал нужен срочно. Каков документооборот в этом случае? Например, в произволном виде пишем служебную записку: "просим приобрести 1 диск по заявке №111 очень срочно всвязи с выходом из строя!" Важность может быть не связана с заявкой и может устанавливаться отдельным документом. При составленнтии новго плана закупок эта важность учтется. Ну вот, в Вашем документообороте наклевываются такие новые понятия: - Коррекция поданной заявки. - "Произвольный вид" - если это так, то для автоматизации этого процесса базы данных не нужны, достаточно ксерокса ;-) Думаю, что документ придется все же формализовать - дата, номер заявки, позиции, новые значения (добавить, убавить, изменить). - Нарисовался новый документ - "План". Причем имеет значение, включена ли заявка в план. Если да - то коррекция будет относиться уже к следующему плану. Нет - просто корректируется исходная заявка, и включается в текущий план. Короче говоря, категорически рекомендую проговорить документооборот без компьютеров, в максимально общем виде, самые немыслимые варианты (типа подана ошибочная заявка, подписана, но не включена в план - операция отмены заявки). Без этого все обсуждение и все структуры смысла не имеют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 12:51 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
es3000Ну у нас считают что это реально нужно. Тут уже неоднократно встречался такой совет: пусть тот, кто считает, что это нужно напишет ТЗ. Если напишет, что сомнительно, тогда вы узнаете в каком виде это нужно и сможете начинать проектировать. А пока, перечитайте топик, вам многие говорят, что задача не формализована и проектировать просто рано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 13:55 |
|
||
|
Как сделать структуру базы для хранения важности заявки
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher Ну вот, в Вашем документообороте наклевываются такие новые понятия: - Коррекция поданной заявки. Согласен Cane Cat Fisher - "Произвольный вид" - если это так, то для автоматизации этого процесса базы данных не нужны, достаточно ксерокса ;-) Думаю, что документ придется все же формализовать - дата, номер заявки, позиции, новые значения (добавить, убавить, изменить). Ну пользователи будут бумажный документ оформлять в произволном виде, а в программу он будет заноситься конечно в формализованном. Cane Cat Fisher - Нарисовался новый документ - "План". Причем имеет значение, включена ли заявка в план. Если да - то коррекция будет относиться уже к следующему плану. Нет - просто корректируется исходная заявка, и включается в текущий план. Про план я почти сразу сказал, что будет такой документ. В план всегда будет включаться самый последний вариант заявки со всеми корреткировками. Но пока для выяснения структуры базы этот документ мне кажется не важен Cane Cat Fisher Короче говоря, категорически рекомендую проговорить документооборот без компьютеров, в максимально общем виде, самые немыслимые варианты (типа подана ошибочная заявка, подписана, но не включена в план - операция отмены заявки). Без этого все обсуждение и все структуры смысла не имеют. В общем-то все возможные варианты уже перечислены. Может быть остановиться на этом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2007, 14:50 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34787983&tid=1544304]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
185ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
| others: | 223ms |
| total: | 539ms |

| 0 / 0 |
