Афигеть!!!!!!!!!!!!!

Люди никогда не видели, как работает и считает зарплаты (или что-то другое) СУБД - особенно учитывая, что все данные табличные и хранятся в ней же???????????

Афигеть окончательно!!!!!!!!

2 mcureenab
Единственный ответ на высказывания выше - это бред, полнейший бред. Травой так не надо увлекаться, плохо кончается это все :)

2 izoldov-roskini
Я искренне тебе советую не слушать чушь, которую несет mcureenab. Как делал, так и делай, все на СУБД.

========
Я конечно все понимаю, но такого кошмара редко увидишь


-- Tygra's --
Мои фотогалереи тут и тут

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 --
Мои фотогалереи тут и тут

Bely tygraЭто во сне приснилось чтоли? Назови хоть одну не маркетинговую причину. Или не "откатную" - чтобы побольше бабла загрести от большего количества систем и серверов.
Широкая филиальная сеть, зонирование ответственности между крупными подразделениями.
Здесь ты не прав.
Большим конторам нужны большие подходы и дело не только в откатах.
Ну это по-разному решается, можно удаленно заходить и работать, можно репликацию.
Вопрос то вообще-то не в этом.
Вопрос в том, кто должен считать
Для филиальной сети можно использовать апп-сервер, но как коммуникатор между клиентом и сервером. И отнюдь он не должен что-то там считать внутри себя типа зарплаты или пени :)
Это сравнение мягкого с теплым :)

iscrafm Сахават Юсифов
Тига прыгает не там и не туда. Лучше в "треп".
:) у него просто меню на постранички вмещается, поэтому и состав продуктов не такой большой. Хватает одной СУБД, в чем собственно он постоянно пытается всех убедить.
Заметьте, я здесь ни за какую конкретно СУБД не ратовал - мне обычно вообще пофиг последние год-два, на чем хотите, на том делайте, вырос из того возраста :)

А вот про "Тига прыгает не там и не туда" я если честно не понял - чего это? :)

-- Tygra's --
Мои фотогалереи тут и тут

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

Филиальная сеть не очень хороший пример - есть много способов, как сделать это без апп-серверов.
Например у нас работает все та же к-с система, и в филиалах, и в центре.

Да и потом - я к чему намекаю про "где считать". К тому, что "где считать" никак не относится к распределенности системы. И распределенность системы не есть "где считать" :)

-- Tygra's --
Мои фотогалереи тут и тут

Папа, ты с кем сейчас разговаривал?



-- Tygra's --
Мои фотогалереи тут и тут