+1 открывший для себя преимущества архитектуры клиент-сервер :)

Вы, товарищ, это... не торопитесь чепчик в воздух бросать. СУБД -- это не вершина прогресса, это парадигма 80-х годов. Чтобы попасть в 90-е, почитайте про трехзвенную архитектуру -- в ней разделяются логика данных и бизнес-логика. А чтобы синхронизоваться с 2000-ми, познакомьтесь с BPM и SOA -- сегодня разделяют уже не только алгоритмы и данные, а выделяют процессы как отдельную сущность.

iscrafmОбеспечьте в браузере нормальный ввод для начала. То же мне, проблема.

Не путайте к.п.д. и максимальную мощность. Из одного и того же процессора двухзвенная система выжмет больше трехзвенной -- у нее выше к.п.д. Но зато у трехзвенной практически линейная масштабируемость (тормозит -- просто поставим еще один сервер приложений), т.е. тут больше максимальная мощность.

МБаза данных все равно у ERP системы одна! и находится на 1-м сервере БД! Ээээ... всегда на одном сервере? И второй вопрос: если бы даже это было так, разве это не означало бы, что его надо максимально разгрузить?

Мода циклична, прогресс поступателен. Что мы имеем в данном случае?

модНе решенная В какой конкретно части не решена проблема ввода информации через браузер?

Мне известно что такое ERP. Адресую Вам тот же вопрос: "В какой конкретно части не решена проблема ввода информации через браузер?" Возможно, Вам просто известны не все существующие на сегодняшний день решения этой проблемы.

Нет, я имею в виду чистые решения без плагинов, ActiveX и прочих аплетов. Конкретно -- AJAX-приложения, по функциональности практически не уступающие "тяжелым" десктопным, и RAD-инструментарий, делающий их разработку опять-таки не сложнее разработки десктопных приложений.

Вот интересно: рассуждения на тему "серебряной пули" я не слышу нигде, кроме как тут на форуме. Зато здесь это универсальный аргумент, успешно заменяющий разговор по существу.

Когда-то давно читал статью в журнале. Автор задает вопрос разработчикам:
- а кто у вас проектирощик схемы БД?
- зачем, мы же пользуемся CASE
- ???!!!!

К чему это я? А, вот! Что, из того что кто-то где-то (пусть даже много раз) использовал новый инструмент не по назначению -- например, зарядил трехзвенную архитектуру, чтобы раскрутить клиента -- автоматически следует что это плохой инструмент?! Если кто-то станет решать задачу из учебника физики с гирями, веревками и блоками, прибегая к аппарату специальной теории относительности -- то это Эйнштейн такой тупой? :)

Я так на это смотрю. У меня есть "чемоданчик с инструментами". Время от времени появляются какие-то новые веяния -- новые инструменты. Я на них смотрю, и если вижу что новый инструмент позволяет делать что-то, с чем мой существующий арсенал не справляется или справляется хуже -- я его добавляю в "чемоданчик". (Конечно, тут возникает вопрос о соотношении эффекта и затрат на освоение нового инструмента, но пока от этого абстрагируемся.) Но выбрасывать из чемодана все инструменты, что в нем были, ради нового (а в этом, как я понимаю, заключается метафора "серебряной пули") -- увольте, это полное безумие. Бывает конечно какие-то инструменты списываются за полным моральным устареванием, но нечасто, нечасто...

Возвращаясь к теме трехзвенки, BPM, SOA -- я лично убежден, что в них эта "дельта добавочной эффективности" присутствует. Причем в задачах ERP (если речь идет о настоящей ERP, без скидок и "как-бы" ERP, состоящей из одного учета) эта дельта весьма значительна.

iscrafmЕсли есть что возразить, с удовольствием послушаю. Это же элементарно, Ватсон!

Суть этой статьи сводится к одному: искра-консоль не хуже браузера. Но, во-первых, любой софт должен существенно превосходить возможности стандартного, чтобы его использование было бы оправдано. Во-вторых, браузер стандартизован. Пусть не идеально, но средств разработки приложений для браузера существует множество. Как насчет средств разработки для искра-консоли? И в-третьих, выясняется, что в искру-консоль встроен браузер. А чем это отличается от браузера с плагином, который Вам кажется не по нраву? По-моему, принципиально ничем.

Alexey Kudinov Впервые об Ajax заговорили после появления в феврале 2005-го года статьи Джесси Джеймса Гарретта. Вы полагаете, за 1.5 года накопилось достаточно решений сделанных на основании этой технологии, что уже можно давать такие смелые оценки А Вы полагаете, что до появления этой статьи эта технология не существовала? Большая ошибка. Например, инструментарий, с которым мы работаем, позволял создавать приложения a-la AJAX где-то с начала двухтысячных, если не 99-го года. (Если сильно интересно, могу уточнить.) Строго говоря, это был не AJAX, но принципы абсолютно те же: обмен с сервером в бэкграунде из javascript, обновление информации на странице без перерисовки, ввод-редактирование-удаление на одной странице, master-detail на одной странице и т.д. Так что оценку я делаю на основании собственного, а не чужого опыта.

И это правильно! В самом деле, зачем опускаться до содержательных аргументов? Сказал "обоснованность упала" - и точка!

А, понял! Ваши, коллеги, представления о возможностях браузера формируются на основания опыта написания комментарий в этом форуме.

Тут каждый отвечат по-существу, не по-существу отвечают только оппоненты.

Вы тоже не расшифровали что такое "работа с данными, которую просто невозможно обеспечить в браузере".

Alexandr Kochminи всетаки об недостатках браузера:
1) нет userDefined HotKey
2) нет Drag'n'Drop
3) тормознутость. Да кто же Вам это рассказал?
1) есть
2) есть
3) тоже есть :) согласен, в соревновании на скорость победит конечно не браузер. но и не "нативный клиент", а мэйнфреймовский терминал!

iscrafmAJAX в общем всего лишь обработка на клиенте XML пакета и верстка на основе его данных страницы Боюсь, что Вы либо не разобрались в этой технологии, либо делаете вид. Суть тут вовсе не в XML - можно при желании гонять plain text, html или что угодно еще. Суть в том, что обмен между клиентом и сервером происходит в фоновом режиме, без перерисовки экрана. Соответственно, все ограничения, присущие веб-приложениям первого поколения, снимаются: все, что нельзя сделать на клиенте, делается на сервере. Вы с gmail работали? А это ведь только 10% возможности технологии.

Petro123Если система может понятно разделить данные обновляемые и нет. Т.е. сможет ли разобраться "при удалении сотрудника вверху - перерисовать фонд зарплаты внизу". :)
Замучитесь программировать. Да нет, не замучаюсь. Программирование этой задачи в AJAX принципиально ничем не отличается от программирования ее же, скажем, в Delphi. С той только разницей, что такая бизнес-логика будет сконцентрирована на сервере.