О'Гурец tygra..Оракл Формс убогий - но Оракл дорогой и его пихают везде, где можно. А об убогости покупатели узнают потом, уже после "прибыльного" вложения капиталла. Но тогда всем уже пофиг..
Любой органо-лептический интерфейс убог по определению.. Вот когда Оракал и иже с ними херувимы всем в башку начнут микросхемы вставлять для убыстрения "интерфейсов" - вот тогда это будет круть :-) Не дай нам бог дожить до такого.. и детей очень жалко - они застанут
--
А сервера-приложений это не для лохов, а для эконом. развитых стран -господа империалисты денег зря не тратят.
Еще как тратят и как правило платят за то ПО, которое увеличит капитализацию их бизнеса, а не за лучшее по ТТХ. А как там рядовые сотрудники мучаются-их не е..волнует.:)

Сисой OTiger
Еще как тратят и как правило платят за то ПО, которое увеличит капитализацию их бизнеса, а не за лучшее по ТТХ. А как там рядовые сотрудники мучаются-их не е..волнует.:)

Пару раз я наблюдал автоматизацию по-европейски. Прошу учесть, что Pentium MMX-II на рабочем месте менеджера серьезной корпорации - отнюдь не редкое явление. Т.е. смена поколений компов происходит гораздо реже, чем у нас (и это объяснимо - там офисный комп стоит 800-1200 баксов, а отнюдь не 300, как у нас).
Зато на серверах не экономят. Соответственно и разработчики ПО стараются строить свои приложения таким образом, чтобы оно максимально грузило сервера (причем лучше 2, чем 1) и минимально - клиентское рабочее место.
И это абсолютно правильный подход!

VladiChЁма-ё... Опять по новой противники/сторонники серверов приложений сцепились.
Противникам сервера приложений еще раз.
Для чего нужны сервера приложений:
1. Возможность работы с разными видами ресурсов. Поверьте, СУБД - это не единственный ресурс, который может потребоваться при разработке систем. Есть еще различные коммуникационные сервисы, почта, очереди сообщений и тому подобные вещи. Откуда управлять этим? С базы данных? С клиента?

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

VladiCh
2. Выдавать данные клиенту в требуемом ему виде. Обычно это некая ORM-прослойка, отдающая клиенту не рекордсеты, а сериализованные объекты. Необходимость этого как правило малопонятна ярым противникам серверов приложений, а чтобы это объяснить, приходится влезать в дебри и конструктивный разговор как правило на этом заканчивается.

Если Вы не умеете выдать клиенту данные в нужном виде без рекордсетов-это Ваша проблема, а не достоинство СП.

VladiCh
2. Масштабирование. Самый избитый аргумент противников серверов приложений в том что типа никакого масштабирования нет, все все равно упирается в СУБД. Возможностей увеличить производительность масса. Самая очевидная для меня - это кэширование. Если построение объектов какого-нибудь типа занимает много времени, то логично будет частоиспользуемые кэшировать. Противники тут же возражают: а чем не нравится кэш СУБД. А тем и не нравится, что его логика может совершенно не пересекаться с логикой приложения. На серверах приложений можно построить распределенный кэш объектов, и этим минимизировать обращения к СУБД.
Прелестно, у нас уже логика приложения вообще никак не завязана на СУБД, а о чем мы тогда вообще говорим?
Лично для меня самая очевидная возможность увеличить производительность, это систему по человечески спроектировать и тогда не понадобиться извращаться с доп. кэшированием и прочей лабудой.

VladiCh
Логически функции хранения данных и функции бизнес-логики должны быть разделены. Как это будет физически организовано - внутри СУБД, вне СУБД - это дело конкретной реализации. Внутри СУБД - быстро, но негибко и не переносимо, поэтому я предпочитаю делать это вне СУБД.

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

отредактировано модератором