2 mcureenab
Я так понимаю, что ты просто не умеешь работать с Ораклом да и вообще с любыми другими СУБД. Не умеешь использовать его так, чтобы он работал нормально, без проблем.
И причем тогда тут СУБД?
Если в расчете зарплаты тебе не хватило PL/SQL, я уж тогда не говорю о TSQL, то я помолчу по поводу уровня знаний - расскажи об этом кому другому, у кого расчеты зарплаты крутятся и на Оракле, и на MS, и на Sybase - наверное у них глюки, да?
Смешно.
Еще раз прошу сходить и прочитать топик "странные мысли о 3-звенном приложении", там на десятках страниц было показано, где хорошо использовать апп-сервер (ничтожное кол-во примеров) и где плохо.
mcureenabЕсли тебя послушать, то и реализация расчёта средствами СУБД тоже бред, ибо я в своих постах допускаю разные варианты реализации, и пытаюсь рассмотреть ++ и -- каждого из них. Я против расчёта средствами СУБД (имею опыт разработок на PL/SQL), поэтому предпочитаю рассматривать -- этого решения, но тут полно народу, который аргументированно высказывает и его ++. К сожалению, ты в их число не входишь.
Кстати, по поводу бреда - я говорил не о том, что апп-сервер - это бред, а о доводах, приведенных в нескольких постах. Могу повторить еще раз - это бред. Такие доводы только для маркетингового развода лохов.
Я не увидел там никаких плюсов и минусов СУБД. Чиста маркетинговое запудривание мозгов.
-------
Еще раз напомню - мы тут обсуждаем расчет зарплаты, а не обсчет сферического коня в вакууме.
------
mcureenab "БЕСПЕРСПЕКТИВНЯК" - точно сказано. Сделать это побыстрому и что бы как то работало, можно средствами СУБД.
Ну если ты не умеешь по-другому работать с СУБД, а только "чтобы как-то", то мы тут причем? :))
авторНо перспектива развития такого решения, ИМХО, сомнительна. Дело в том, что мир идёт к распределёным вычислениям. Централизация, это не модно и, видимо, на то есть не только маркетинговые причины.
Это во сне приснилось чтоли? Назови хоть одну не маркетинговую причину. Или не "откатную" - чтобы побольше бабла загрести от большего количества систем и серверов.
авторМогу допустить, что в перспективе потребуется интегрировать модуль расчёта ЗП в информационную систему масштаба предприятия развёрнутую на AS. И что тогда? Это не приговор, а вопрос, как это сделать?
И что, какие проблемы? Или трава настолько глубоко проникла, что ты не можешь представить себе апп-сервер без расчетов? Апп-сервер, который только данные гоняет от клиента к серверу и обратно, не можешь этого представить? Тогда о чем говорить?
Я например могу представить такое - зачем-то втыкаем между клиентом и сервером 3-е звено, которое служит коммуникатором. Зарплату как и до этого считает сервер.
И эти люди говорят о моей категоричности
авторНу в общем лично меня в основном бодают слабые выразительные средства PL/SQL и небольшая, по сравнению с универсальными языками программирования, библиотека, невысокая производительность (зато очень просто и надёжно, что часто является решающим фактором!). Нет автономной реализации PL/SQL машины, такой как например JVM. Опять же PL/SQL не решает все задачи, по любому приходится использовать универсальные ЯП (C++), т.е. вместо одного специалиста в C++, к проекту нужно привлекать ещё разработчика PL/SQL. В итоге, рано или поздно первую версию вычислительного модуля, разработанную на PL/SQL приходится переписывать на C++.
Ну давай, расскажи, где тебе не хватило PL/SQL?
Зачем тебе PL/SQL-машина - что за бред вообще? Вот блин джава ....
И какие задачи не решает PL/SQL?
Или может просто не умеешь это все готовить? Ну тогда извини - купи поварскую книгу. :)
-- Tygra's --
Мои фотогалереи тут и тут 
