Реализация бизнес логики приложения

← →
Sinus © (2007-03-26 13:29) [0]

привет всем.

есть программа написанная на Clipper, предназначенная для обработки стат. данных. В связи с резким увеличением нагрузки на операторов вводящих данные( количество отчетов увеличилось в 1,5 раза ) , возникла необходимость сетевой версии программы( Firebird 1.5.3 ). в старой программе арифметический и логический контроль реализовывался следующим образом..

1. есть таблица с данными отчетов

id_kod kod g1 g2 g3 g4
3432 101 455,23 150,86 - -
3432 111 400,23 50,86 - -
3432 112 55,0 100,86 - -

то есть сумма по коду строки отчета 101 должна равняться
=111+112
2. есть таблица в которой эти правила записанны ввиде формул

kod znak uslov
101 = 111+112

Вопрос:
1. объясните как это в принципе может быть реализованно( через фильтр, запрос.. или еще как ???) по тому как мне сложно представить фильтр котрый сравнивает поля 2- х разных записей...

2. и если возможно объяснить как это можно реализовать в Firebird

плиз прошу отнестись с уважением и не пинать сильно ;-)

← →
Val © (2007-03-26 13:37) [1]

stored procedure

← →
sinus © (2007-03-26 13:50) [2]

> stored procedure

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

меня интересует именно такой вариант

← →
Sergey13 © (2007-03-26 14:17) [3]

> [2] sinus © (26.03.07 13:50)
> видимо ты имел ввиду что надо жестко записать все правила в процедурах,
Видимо он имел в виду, что в хранимке можно реализовать парсинг формулы, из таблицы формул, и сформировать запрос, который вернет нужный результат.

Хранить исходные данные и подсчитанные вроде как некошерно в этом случае.

← →
Jan (2007-03-26 14:18) [4]

> 2. есть таблица в которой эти правила записанны ввиде формул
>
> kod znak uslov
> 101 = 111+112

а почему не просто два поля: ссылка на главный счет, и ссылка на подчененные?
А контроль будет вида:
select * from table1 t1
where (select sum(g1) from table1 t2
where t2.kod = t1.kod) <> (select sum(g1) from table1 t3
where exists(select * from table2 t4
where t3.kod = t4.subkod
and t4.kod = t1.kod))

← →
Jan (2007-03-26 14:23) [5]

вместо <> надо not:
select * from table1 t1 where not (select sum(g1) from table1 t2 where t2.kod = t1.kod) = (select sum(g1) from table1 t3 where exists(select * from table2 t4 where t3.kod = t4.subkod and t4.kod = t1.kod))

← →
Petr V. Abramov © (2007-03-26 14:36) [6]

в FB есть динамический sql

← →
sinus © (2007-03-26 15:50) [7]

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

спасибо это более интересный вариант, чем все жестко прописывать..
надо попробывать

← →
ANB © (2007-03-26 17:03) [8]

> sinus © (26.03.07 15:50) [7]

Судя по всему, в программе на клиппере использовались макросы.
Аналог макросов - динамический SQL.
Кистате, а кто мешает работать в сети на клиппер-программе ? Он хоть и файл-серверный, но человек 5 пользователей без проблем тянуть должен.

← →
sinus © (2007-03-26 20:59) [9]

спасибо всем за советы ,сейчас решаю что удобнее и быстрее реализовать
динамический SQL или парсить данные из процедуры.

> Кистате, а кто мешает работать в сети на клиппер-программе
> ? Он хоть и файл-серверный, но человек 5 пользователей без
> проблем тянуть должен.

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

← →
Val © (2007-03-26 22:49) [10]

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

← →
Petr V. Abramov © (2007-03-26 23:01) [11]

> Val © (26.03.07 22:49) [10]
... либо когда он может меняться по воле юзера. тчк.

← →
ANB © (2007-03-27 11:54) [12]

> этот способ не подходит так как возможна ситуация, когда
> одновременно будет работать более 10 человек операторов,
> которые "вбивают " данные с приличной скоростью :-)

Не факт, что новая программа юудет работать намного шустрее, чем клипперовая. А вы тесты на 10 человек проводили ?

> да и уровень написания программ на клипере средний..

Чтобы это значило ? Я более крутого языка, чем клиппер 5.2 еще не видел.

← →
Jan (2007-03-27 12:03) [13]

> Не факт, что новая программа юудет работать намного шустрее,
> чем клипперовая. А вы тесты на 10 человек проводили ?

а проводили тесты на базе в 60 ГБ и нагрузкой в 150-200 человек?

> а проводили тесты на базе в 60 ГБ и нагрузкой в 150-200
> человек?

Я проводил тесты с нагрузкой, правда всего 10 человек, но на базе в 160 Террабайт.

ИМХО - и МС СКЛ и ФБ такой нагрузки не выдержат тоже.

← →
Jan (2007-03-27 12:36) [15]

> Я проводил тесты с нагрузкой, правда всего 10 человек, но
> на базе в 160 Террабайт.

может Мбайт?

> ИМХО - и МС СКЛ и ФБ такой нагрузки не выдержат тоже.

для МС 60Гб с нагрузкой в сотню пользователей - пустяк... Для ФБ не пробовал.

> может Мбайт?

Нет, именно террабайт. Меня сильно поразила разница в работе приложения у нас на тестовой базе и на этой - слепке с рабочей.

Я к тому, что у каждой СУБД своя область применения. Если база не очень большая, то вполне может оказаться, что дешевле не переписывать все с клиппера.

← →
Jan (2007-03-27 15:03) [17]

> Нет, именно террабайт.

прикольно. я таких и не видел :)
Ну и как выборки? Шустренько?

> Ну и как выборки? Шустренько?

По первичному ключу, если хинтануть - то шустро. Но сильно влияет еще селективность индексов. Впрочем, сразу признаюсь - это был мой первый опыт работы с такой огромной базой, собственно в оптимизации я не силен, если бы не сидел 10 лет на клиппере - вообще бы плавал.
Там и сервак - 64 бита, 16 процов, 64 гектара озу, оракла 64 бита. Т.е. все круто.

Реализация бизнес логики приложения Найти похожие ветки