Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.06.16;
Скачать: [xml.tar.bz2];

Вниз

Проблема с постановкой задачи.   Найти похожие ветки 

 
Ler   (2003-05-23 16:19) [0]

Рябята, помогите разобраться с постановкой задачи!

Заказчик ставит задачу так:

Есть предприятие, имеющее ряд филиалов. Некоторые из филиалов имет свои подфилиалы.
То-бишь навязывает иерархию. Ну это абсолютно нормально. Никто не гарантирует, что у подфилиалов не возникнет подподфилиалов!
Далее, надо написать складскую прогу по учету движения некоторых материалов и списанию их в производство (FIFO-шную) по всей этой иерархии. Т.е. заказчик хочет сам за все вершинки этого дерева вести операции по перемещению материалов(за себя и за того парня).

Например:

Наше головное предприятие называется Dork.
Dork покупает материалы у, например, A,B и D и еще бог знает у кого.
Dork распихивает эти материалы по филиалам. Те, в свою очередь, списывают их в производство, если у них нет подфилиалов, а если подфилиалы есть, то передают им, а те уже гонят материал в производство.
Возможен, естественно и возврат материала.

Я думаю, что логично, написать просто складскую прогу учитывающую операции фирмы Dork, то-бишь:
Приход от поставщика, Возврат поставщику, Отгрузка получателю, Возврат от получателя.
Для филиалов, которые имеют свои подфилиалы, надо просто ставить на компе свои алиасы, где будут учитыватся их собственные операции по движению матералов, а программа просто должна уметь коннектится к ним по выбору пользователя . И вся ответсвенность за непротиворечивость данных в этом случае ложится на пользователя.
Здесь я имею ввиду, что если Dork отгрузил филиалу F материал, а этот филиал имеет свои подфилиалы, то пользователь сам должен позаботится, чтобы расходная операция Dork->F Исх.№222 от "01/01/2003" оформленная в алиасе DorkAlias была в точности идентичной приходной операции у филиала F : F<-Dork от "01/01/2003" внешний №222 в алиасе FAlias.
Если же Dork передает материалы непосредственно филиалу, а филиал списывает материалы в производство , то его(этот филиал) в базе можно хранить как Склад: передавать материал на склад, списывать с этого склада в производство.

Т.е. Dork имеет след. склады:

F // это промежуточный филиал, для него будем созавать отдельный алиас
// и операции по передаче материалов в подчиненные филиалы будем
// вести в его собственном алиасе FAlias;
G // терминальный филиал, в производство будем списывать в алиасе DorkAlias;
. // Ну и т.д.
.
.
Z

Заказчик думает иначе.Все в рамках одного алиаса и дублировать информацию он не будет.

Я ВАС ЕЩЕ НЕ ДОСТАЛ ???

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

Хелп!!!


 
fool   (2003-05-23 16:53) [1]

1.клиент всегда прав
2.если клиент не прав, смотри 1.


 
Ler   (2003-05-23 17:02) [2]

2 fool
Мне не до шуток...


 
fool   (2003-05-23 17:12) [3]

Если не до шуток, то твоя затея выглядит логично, но не совсем понятна точка зрения заказчика (его видение программы), что, например значит
>Все в рамках одного алиаса и дублировать информацию он не будет.
поэтому выявить противоречя в ваших взглядах так слету проблематично


 
Zacho   (2003-05-23 17:16) [4]

Алиасы к этому мало отношения имеют :-) . Подумай над термином "репликация".


 
Ler   (2003-05-23 18:25) [5]

2 fool

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

>что, например значит
>Все в рамках одного алиаса и дублировать информацию он не будет.

Это значит, что оформив у себя операцию пекредачи материала Dork->F, автоматически должна генериться операция у F: F<-Dork (F получил материал от Dork)

2 Zacho

1. Ваш протест про алиасы отклонен. Если устраивает, замени Алиас на БД.
2. Про репликацию если заговорили, то давай подробнее : твое концептуальное решение в студию.



 
fool   (2003-05-23 18:44) [6]

Заказчик тоже по-своему прав, по его реализации, он будет видеть реальную информацию, т.е. не зависеть от произвола тупых юзеров на местах, и при необходимости дрючить тех, у кого неверная отчетность. К тому же при разбиении на филиалы довольно сложная задача поддержавать данные в удаленных местах в актуальном виде. А так сделал реплики БД филиалам и уверен, что все работают с единообразной информацией. И дрючить, дрючить, дрючить тех, у кого отличаеться :)


 
Ler   (2003-05-23 18:55) [7]

2 fool © (23.05.03 18:44)

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

Зришь в корень!!! Именно этого он и хочет.

>А так сделал реплики БД филиалам и уверен, что все работают с единообразной информацией.

Извини, я в репликах не дока. Реплика, это когда исходящий документ от Dork к F автоматически генерится для F как входящий (F<-Dork) с атрибутом read-only ??? Будь любезен, объясни несчастному !


 
Sandman25   (2003-05-23 18:57) [8]

Ler
Надо завести систему участков и операцию перемещения с участка на участок. При списании и оприходовании нужно указывать участок.


 
Ler   (2003-05-23 18:59) [9]

2 Sandman25 © (23.05.03 18:57)

Подробнее...


 
fool   (2003-05-23 19:35) [10]

Replica - буквальный перевод "копия", а конкретное использование репликации несколько отличаеться в различных СУБД, так что разбирайся на месте.


 
Ler   (2003-05-23 19:41) [11]

2 fool & All

Спасибо!
Если еще есть идеи , комментарии, буду признателен.
Еще раз Всем Спасибо!


 
Sergey13   (2003-05-26 09:41) [12]

2Ler (23.05.03 19:41)
Присоединюсь к Sandman25 © (23.05.03 18:57)
С теоретической точки зрения тут другого ничего вообще быть не может, ИМХО. Передача между подразделениями и списание на производство это разные вещи и учитываются они соответственно по разному. Как эту разницу описать - тут можно спорить до хрипоты, хотя спорить то особо не о чем - как сделаешь, чтоб работало, так и правильно будет. 8-)
С практической точки зрения, как это сделать зависит от аппаратной реалиазации твоей сети и СУБД, которую используешь (или собираешься). Например важен вопрос - связь между филиалами постоянная или сеансовая? Филиалы могут сами что то закупать на стороне? Вообще они справочники могут править или только читать? Если все "по максимуму", то я тебе не завидую. 8-(



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2003.06.16;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.49 MB
Время: 0.013 c
1-50373
sts
2003-05-30 08:18
2003.06.16
преобразование даты в строку


1-50356
Plasticangel
2003-06-02 13:08
2003.06.16
Как работать с нетипизированым файлом....


14-50439
Deflorator+
2003-05-22 14:25
2003.06.16
Залить фигню типа


14-50436
Basic
2003-05-28 01:44
2003.06.16
Ошибка при работе с Rave


14-50517
Gor
2003-05-31 16:11
2003.06.16
Чем грозит трепанация черепа ?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский