| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Триггеры в master-detail [IB6.x]
deras © (2007-05-21 15:36:00)есть 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?
Sergey13 (2007-05-22 10:31:00) [81]> [25] deras © (22.05.07 10:21)
> я так думаю
Думать - мало. Надо знать на 100%.
Никто не запрещает
1. не заполнять некоторые атрибуты в таблицах
2. создавать отдельные таблицы с атрибутами, необходимыми в отдельных случаях.
Вообще первоначально надо точно определиться с системой учета (партионность, FIFO-LIFO, взвешенные цены и т.п.) и с тем, какие даные ты хочешь иметь на выходе. В какие другие внешние системы твой склад возможно будет встраиваться. И т.д.
ЗЫ: Ты пишешь реальный проект или курсовую?
Сергей М. (2007-05-22 10:30:00) [82]
> серийник товара, который в приходе сбсно не нужен
У товара нет "серийника".
Серийный номер - необязательный атрибут изделия. Изделие само по себе не обязано быть товаром. А коль оно у тебя стало товаром, то оно стало им именно на этапе прихода.
deras (2007-05-22 10:21:00) [83]Я понимаю, что нельзя это обсудить в рамках форума, но все же....
>Не надо делить расход-приход по разным таблицам
А если стр-ра таблиц отличается. Например, в расходе надо указывать серийник товара, который в приходе сбсно не нужен (я так думаю)
Sergey13 (2007-05-22 09:51:00) [84]> [22] deras © (22.05.07 09:32)
> Раз Вы говорите, значит, действительно просто...
Я не говорил "просто". Я говорил, "просто твоя боязнь сложных вопросов не являяется критерием проектирования".
Просто/сложно - все относительно. Надо разбираться (или иметь грамотного консультанта/постановщика) в предметной области. Тогда проще становится.
Склад - это классика. Все его делали. Но желательно его сделать самому (не отменяя разумеется чтения по теме).
> В чем ошибка такой стр-ры?
Да во всем. Не надо делить расход-приход по разным таблицам. Не надо сводить несколько таблиц в одну для "облегчения" запросов.
Сергей М. (2007-05-22 09:48:00) [85]
> В чем ошибка такой стр-ры?
Основная ошибка - в ничем не обоснованной тобой избыточности информации, имеющей место быть в связи с самим существованием таблицы KUB в том виде, в каком ты ее представил.
deras (2007-05-22 09:32:00) [86]>А самому подумать? Тут вобщем то ничего особо сложного нет. Просто
Спасибо на добром слове. Серйозно. А то накинулись тут товарищи на неопытного...
Раз Вы говорите, значит, действительно просто... Но если б кто-то подсказал, подтолкнул т.ск.
В чем ошибка такой стр-ры?
Sergey13 (2007-05-22 09:15:00) [87]> [20] deras © (22.05.07 09:06)
На все то мы ссылки ищем. 8-)
А самому подумать? Тут вобщем то ничего особо сложного нет. Просто
> [11] deras © (21.05.07 17:27)
> для упрощения создания запросов - чтоб не создавать сложных запросов
это не критерий проектирования БД. Это показатель отсутствия теоретических знаний.
Тебе по теории надо почитать/подтянуться. Нормальные формы всякие, непротиворечивость данных и т.п.
deras (2007-05-22 09:06:00) [88]>Тебе не с тригерами надо разбираться а с проектированием БД. Серьезно разбираться
согласен... есть ссылки на примерное описание с-ры базы склада?
deras (2007-05-22 09:03:00) [89]>Совершенно бредовая модель.
Предложите лучшую модель. Или дайте ссылку, где почитать
>Программисту, задающие такие вопросы, рановато браться за складские программы
Начинать когда-то надо. Вы тоже когда-то былы на низком уровне знаний. И я попросил совета, а не оценки моего уровня знаний в программировании
Sergey13 (2007-05-22 08:55:00) [90]> [14] deras © (21.05.07 17:53)
Ну ты и нагородил! Тебе не с тригерами надо разбираться а с проектированием БД. Серьезно разбираться.
ЗЫ: без всяких наездов и желания обидеть.
Jan1 (2007-05-21 18:43:00) [91]
> А таблица KUB предназна для организации статистики по разным
> параметрам. Например: Найти колличество товара с id_sklad=2
> select sum(KOLVO) from KUB where id_sklad=2
учить SQL. И надеюсь это у тебя курсовая а не реальный проект...
ANB (2007-05-21 18:14:00) [92]ЗЫ. Программисту, задающие такие вопросы, рановато браться за складские программы. ИМХО.
ANB (2007-05-21 18:13:00) [93]
> Это упрощенная модель БД учета складского прихода/расхода
Совершенно бредовая модель.
deras (2007-05-21 17:53:00) [94]Это упрощенная модель БД учета складского прихода/расхода
T-MAIN и T_CHILD представляют собой таблицы документов прихода на склад
Еще будут две такие же таблицы для расхода.
Записи по приходу (кол-во и сумма) заносятся в KUB с "+", а по расходу - со знаком "-"
А таблица KUB предназна для организации статистики по разным параметрам. Например: Найти колличество товара с id_sklad=2
select sum(KOLVO) from KUB where id_sklad=2
Jan1 (2007-05-21 17:36:00) [95]
> для упрощения создания запросов - чтоб не создавать сложных
> запросов
что значит сложных? тебе зачем таблица KUB?
deras (2007-05-21 17:30:00) [96]>А еще удалить поля ID_KONTRAG, ID_SKLAD - лишние.
Вы имеете ввиду, чтоб стр-ра таблицы KUB была такая?
ID, ID_MAIN, ID_CHILD, ID_PARENT, KOLVO, CENA, SUMA
deras (2007-05-21 17:27:00) [97]>Вообще не понятно, зачем хранить дубли и то, что можно посчитать на лету?
для упрощения создания запросов - чтоб не создавать сложных запросов
Jan1 (2007-05-21 17:23:00) [98]
> Вообще не понятно, зачем хранить дубли и то, что можно посчитать
> на лету?
я так понимаю ему для OLAP нада. А это как правило хранят.
Jan1 (2007-05-21 17:22:00) [99]
> надо ли добавить в таблицу KUB поле ID_CHILD (для U/D)?
надо. А еще удалить поля ID_KONTRAG, ID_SKLAD - лишние.
Desdechado (2007-05-21 17:16:00) [100]Вообще не понятно, зачем хранить дубли и то, что можно посчитать на лету?
| |
Страницы: 