Триггеры в master-detail

← →
deras © (2007-05-21 15:36) [0]

есть 3 таблицы:
1) Главная T_MAIN
Поля: ID, ID_KONTRAG, ID_SKLAD

2)Подчиненная T_CHILD
Поля: ID, ID_PARENT, KOLVO, CENA, SUMA

T_CHILD.ID_PAREN -> T_MAIN.ID

3) Таблица KUB
Поля: ID, ID_KONTRAG, ID_SKLAD, KOLVO, CENA, SUMA

Как повесить триггеры (After INS/UPD/DEL) на какую-то из T_MAIN или T_CHILD (точно не знаю), чтоб данные попадали в таблицу KUB?

← →
Johnmen © (2007-05-21 15:55) [1]

> Как повесить

Так, как описано в документации.

← →
Sergey13 © (2007-05-21 15:56) [2]

> [0] deras © (21.05.07 15:36)
> на какую-то из T_MAIN или T_CHILD (точно не знаю), чтоб
> данные попадали в таблицу KUB?

Из какой таблицы данные, на ту и вешай.

← →
deras © (2007-05-21 16:25) [3]

> Из какой таблицы данные, на ту и вешай.

В том -то и дело, что данные из двух таблиц помещаются в одну. Пример:

T_Main: T_CHILD:
1 2 1 1 1 20 8.5 170
2 1 10 6.1 61
3 1 15 10 150

Таблица KUB должна быть заполнена так
1 2 1 20 8.5 170
1 2 1 10 6.1 61
1 2 1 15 10 150

Как такое раелизовать?

← →
Sergey13 © (2007-05-21 16:31) [4]

> [3] deras © (21.05.07 16:25)

ну так на T_CHILD однозначно.

← →
deras © (2007-05-21 16:39) [5]

>ну так на T_CHILD однозначно.
надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?

Приведите пример для инсерта, пожалуйста

← →
Sergey13 © (2007-05-21 16:49) [6]

> [5] deras © (21.05.07 16:39)
> надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?

А я откуда знаю, что такм нужно?

> Приведите пример для инсерта, пожалуйста

insert into KUB (ID, ID_KONTRAG, ID_SKLAD, KOLVO, CENA, SUMA) select ID, ID_KONTRAG, ID_SKLAD, :new.KOLVO, :new.CENA, :new.SUMA from T_MAIN where :new.id_parent=T_MAIN.id

Если в полях не запутался, то как то так.

← →
deras © (2007-05-21 17:05) [7]

>> надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?

>А я откуда знаю, что такм нужно?

Я почему спросил... Как тогда обновлять и удалять? На какое поле ориентироваться?

← →
Desdechado © (2007-05-21 17:16) [8]

Вообще не понятно, зачем хранить дубли и то, что можно посчитать на лету?

← →
Jan1 © (2007-05-21 17:22) [9]

> надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?

надо. А еще удалить поля ID_KONTRAG, ID_SKLAD - лишние.

← →
Jan1 © (2007-05-21 17:23) [10]

> Вообще не понятно, зачем хранить дубли и то, что можно посчитать
> на лету?

я так понимаю ему для OLAP нада. А это как правило хранят.

← →
deras © (2007-05-21 17:27) [11]

>Вообще не понятно, зачем хранить дубли и то, что можно посчитать на лету?

для упрощения создания запросов - чтоб не создавать сложных запросов

← →
deras © (2007-05-21 17:30) [12]

>А еще удалить поля ID_KONTRAG, ID_SKLAD - лишние.

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

ID, ID_MAIN, ID_CHILD, ID_PARENT, KOLVO, CENA, SUMA

← →
Jan1 © (2007-05-21 17:36) [13]

> для упрощения создания запросов - чтоб не создавать сложных
> запросов

что значит сложных? тебе зачем таблица KUB?

← →
deras © (2007-05-21 17:53) [14]

Это упрощенная модель БД учета складского прихода/расхода

T-MAIN и T_CHILD представляют собой таблицы документов прихода на склад
Еще будут две такие же таблицы для расхода.

Записи по приходу (кол-во и сумма) заносятся в KUB с "+", а по расходу - со знаком "-"

А таблица KUB предназна для организации статистики по разным параметрам. Например: Найти колличество товара с id_sklad=2
select sum(KOLVO) from KUB where id_sklad=2

← →
ANB © (2007-05-21 18:13) [15]

> Это упрощенная модель БД учета складского прихода/расхода

Совершенно бредовая модель.

← →
ANB © (2007-05-21 18:14) [16]

ЗЫ. Программисту, задающие такие вопросы, рановато браться за складские программы. ИМХО.

← →
Jan1 (2007-05-21 18:43) [17]

> А таблица KUB предназна для организации статистики по разным
> параметрам. Например: Найти колличество товара с id_sklad=2
> select sum(KOLVO) from KUB where id_sklad=2

учить SQL. И надеюсь это у тебя курсовая а не реальный проект...

← →
Sergey13 © (2007-05-22 08:55) [18]

> [14] deras © (21.05.07 17:53)

Ну ты и нагородил! Тебе не с тригерами надо разбираться а с проектированием БД. Серьезно разбираться.

ЗЫ: без всяких наездов и желания обидеть.

← →
deras © (2007-05-22 09:03) [19]

>Совершенно бредовая модель.

Предложите лучшую модель. Или дайте ссылку, где почитать

>Программисту, задающие такие вопросы, рановато браться за складские программы

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

← →
deras © (2007-05-22 09:06) [20]

>Тебе не с тригерами надо разбираться а с проектированием БД. Серьезно разбираться

согласен... есть ссылки на примерное описание с-ры базы склада?

← →
Sergey13 © (2007-05-22 09:15) [21]

> [20] deras © (22.05.07 09:06)

На все то мы ссылки ищем. 8-)
А самому подумать? Тут вобщем то ничего особо сложного нет. Просто

> [11] deras © (21.05.07 17:27)
> для упрощения создания запросов - чтоб не создавать сложных запросов

это не критерий проектирования БД. Это показатель отсутствия теоретических знаний.
Тебе по теории надо почитать/подтянуться. Нормальные формы всякие, непротиворечивость данных и т.п.

← →
deras © (2007-05-22 09:32) [22]

>А самому подумать? Тут вобщем то ничего особо сложного нет. Просто

Спасибо на добром слове. Серйозно. А то накинулись тут товарищи на неопытного...

Раз Вы говорите, значит, действительно просто... Но если б кто-то подсказал, подтолкнул т.ск.

В чем ошибка такой стр-ры?

← →
Сергей М. © (2007-05-22 09:48) [23]

> В чем ошибка такой стр-ры?

Основная ошибка - в ничем не обоснованной тобой избыточности информации, имеющей место быть в связи с самим существованием таблицы KUB в том виде, в каком ты ее представил.

← →
Sergey13 © (2007-05-22 09:51) [24]

> [22] deras © (22.05.07 09:32)
> Раз Вы говорите, значит, действительно просто...

Я не говорил "просто". Я говорил, "просто твоя боязнь сложных вопросов не являяется критерием проектирования".
Просто/сложно - все относительно. Надо разбираться (или иметь грамотного консультанта/постановщика) в предметной области. Тогда проще становится.
Склад - это классика. Все его делали. Но желательно его сделать самому (не отменяя разумеется чтения по теме).

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

← →
deras © (2007-05-22 10:21) [25]

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

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

← →
Сергей М. © (2007-05-22 10:30) [26]

> серийник товара, который в приходе сбсно не нужен

У товара нет "серийника".

Серийный номер - необязательный атрибут изделия. Изделие само по себе не обязано быть товаром. А коль оно у тебя стало товаром, то оно стало им именно на этапе прихода.

← →
Sergey13 © (2007-05-22 10:31) [27]

> [25] deras © (22.05.07 10:21)
> я так думаю

Думать - мало. Надо знать на 100%.
Никто не запрещает
1. не заполнять некоторые атрибуты в таблицах
2. создавать отдельные таблицы с атрибутами, необходимыми в отдельных случаях.

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

ЗЫ: Ты пишешь реальный проект или курсовую?

← →
deras © (2007-05-22 10:49) [28]

>Ты пишешь реальный проект или курсовую
Проект. Только не надо издевательств по этому поводу... :-)

Это простая программа учета товара на складе. Надо док-ты:
- приход товара
- перемещение
- списание
- продажа
- инвентаризация
- переоценка

Отчеты:
- доход за период
- обороты (колличественные) товара за период

> Это простая программа учета товара на складе.

Простая программа в любом случае вылезет потом в сложную.
Для справки. Стоимость нормальной складской программы порядка 500 килобаксов. Если это реальный проект, то :
1. Ты взялся пока за непосильную задачу. Ее можно решить упрощенно, но лучше пока в качестве тренировки, не выводя задачу на реал.
2. Тебя конкретно обувают с этим заказом.

> - доход за период
> - обороты (колличественные) товара за период

Это бухгалтерские отчеты, а не складские.

> Это бухгалтерские отчеты

Правильно. А это значит, что придется вести еще и бух.учет на основании документов.

Правильно. И это опять же говорит либо о полной некомпетенции Заказчика и Подрядчика либо об "обувке".

>Ее можно решить упрощенно, но лучше пока в качестве тренировки

Приблизительно это я и хочу сделать. Но даже для тренировки надо знать КАК энто сделать.
Потому и спрашиваю у знающих людей совета....

> deras © (22.05.07 11:04) [33]

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

Без этого даже начинать не стОит.

> [28] deras © (22.05.07 10:49)
> Только не надо издевательств по этому поводу... :-)

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

> - приход товара
> - перемещение
> - списание
> - продажа
> - переоценка
Это все движение товара.

> - продажа
> - доход за период
> - обороты (колличественные) товара за период

Значит уже не просто склад, а склад+магазин? Розница? Опт? И то и это?

Это проект под конкретный магазин или ты хочешь создать нечто универсальное?

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

> Потому и спрашиваю у знающих людей совета....

Не, это не здесь надо спрашивать. Когда я писал склад + бухгалтерия в весьма упрощенном виде, со мной сидел главбух и в течение двух месяцев старательно разжевывала основы бух учета и складского учета. А потом я уже взялся за таблицы. Да и получилось только с третьего раза.
Совет - поискать инфу по бух учету и складскому учету. Или сесть с заказчиком (точнее его бухом) и нарисовать все на бумажке.

> [33] deras © (22.05.07 11:04)

http://www.sql.ru/forum/actualtopics.aspx?bid=36

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

понял... Надо учить матчасть.....
Огромное все спасибо!

Может, мое мнение тут ни к чему, но. Очень уважительно отношусь к конструктивным ответам, а не просто типа "читай теорию" или "зайди на sql.ru - там все есть"

З.Ы. Хотел спросить, что имеется ввиду, когда говорите от "обувке"? Что это значить?

> [38] deras © (22.05.07 11:40)
> а не просто типа "читай теорию" или "зайди на sql.ru - там все есть"
Так говорят то так тоже не просто так. А часто потому, что ответ лежит или на первой странице по F1 (справкой надо пользоваться) или когда ответ предполагает целую лекцию по основам, которые уже описаны в книгах.
В твоем случае - второй вариант. Некоторый базиз должен быть прочитан и понят прежде чем идти сюда (куда либо вообще) и спрашивать про проектирование (кстати ты спрашивал даже не про проектирование, а про реализацию неправильно спроектированного решения - почувствуй разницу). А проектирование вообще штука тонкая и неоднозначная. И коротко на такие вопросы отвечать довольно сложно. При том, что начальных условий ты так до сих пор и не объявил.

>При том, что начальных условий ты так до сих пор и не объявил

Чего ж не объявил? Коротко это звучит как [28]

Триггеры в master-detail Найти похожие ветки