На сколько оправдана концепция ОПП в средствах разработки ERP-систем?

[ibc]

Цитата:

P.S.S. Подтверждение недостаточности реляционной архитектуры, можно увидеть в любой промышленной СУБД. Сложные языки хранимых процедур, тригера, вьюхи, это эмуляция объектного подхода. Прямое изменение данных таблиц считается дурным тоном, т.к. часто эти изменения должны отразиться еще в несколько таблиц, а до конца структуру данных не знает никто.

В этом что-то есть! Все равно даже если бы было ОЗУ в неск. Терабайтов, то нет идеи - КАК ХРАНИТЬ данные! И запросы делать по объектам Си++ неудобно, скажем будет через ООП эмуляция тех же реляционных СУБД, в объектах неудобно хранить информацию, которая используется в ЕРП-системах, или вы не согласны?

[macklakov]

Цитата:

Сообщение от ibc

Все равно даже если бы было ОЗУ в неск. Терабайтов, то нет идеи - КАК ХРАНИТЬ данные! И запросы делать по объектам Си++ неудобно, скажем будет через ООП эмуляция тех же реляционных СУБД, в объектах неудобно хранить информацию, которая используется в ЕРП-системах, или вы не согласны?

Вас сильно волнует, как данные хранятся в бэкапе? Ведь рабочие будут в памяти, в виде объектов. В этом вся фишка, что данные не нужно получать и сохранять, они все время под рукой.

Цитата:

Сообщение от ibc

И запросы делать по объектам Си++ неудобно, скажем будет через ООП эмуляция тех же реляционных СУБД, в объектах неудобно хранить информацию, которая используется в ЕРП-системах, или вы не согласны?

Часть, конечно, останется в табличной форме, т.к. это наиболее естественно. К примеру, таблица закзов. Но вот строки заказов, это уже атрибуты самих заказов. А колличество запросов и их сложность резко снизится, т.к. к запросы по связанным таблицам, это скорее исключение.
P.S. Это при условии, что будет принята идеология J2EE, а не набор ad hoc-ов, который мы сейчас имеем, когда и микроскоп не микроскоп, если гвоздь им не забить и кувалда плоха, если у нее оптический прицел не позволяет микробов рассматривать

[ibc]

Сейчас в небольших корпарациях объем базы 2-3 Гига, озу серверов 32-64 Мега, так что уже можно использовать ЕРП на объектах Джавы, но увы - никто их писать не собирается, очевидно что то в вашей теории их не устраивает, а вот если бы все устраивало, такие учетные системы имели бы коммерческое применение!

[macklakov]

Цитата:

Сообщение от ibc

Сейчас в небольших корпарациях объем базы 2-3 Гига, озу серверов 32-64 Мега, так что уже можно использовать ЕРП на объектах Джавы, но увы - никто их писать не собирается, очевидно что то в вашей теории их не устраивает, а вот если бы все устраивало, такие учетные системы имели бы коммерческое применение!

Пишут, но мало, т.к.:
1. Клиенты на Java тормозят, а сервера приложений недостаточно проработаны. Из-за этого негативное отношение к технологии
2. Не так много людей, которые понимают ООП, а тем более серверные приложения
3. Не вкладываются деньги в продвижение
4. Почти все присутствующие на рынке ERP создавались до появления J2EE

Не ООП, но исходя из тех же предпосылок появился прием, когда 1С разгоняют, помещая файлы данных в ОЗУ
P.S. Подумал о 1С и сформулировалась еще одна причина:
5. Сама технология молода. Ведь даже через 20 лет после появления промышленных РБД, продолжали делать системы основанные на файловом хранении и мотивировали тем, что так проще.

[Pavel]

Цитата:

Сообщение от macklakov

Ведь рабочие будут в памяти, в виде объектов. В этом вся фишка, что данные не нужно получать и сохранять, они все время под рукой.
...
Часть, конечно, останется в табличной форме, т.к. это наиболее естественно. К примеру, таблица закзов. Но вот строки заказов, это уже атрибуты самих заказов. А колличество запросов и их сложность резко снизится, т.к. к запросы по связанным таблицам, это скорее исключение.
…
Это при условии, что будет принята идеология J2EE, а не набор ad hoc-ов...

Зачем все собирать в кучу, методы хранения информации, методы представления объектов в приложении, способы их технической реализации, пользовательские интерфейсы… а затем все в J2EE и против РБД?

Не понятна целесообразность такого подхода. Какая преследуется цель? В чем ее практическая ценность?

«Память будет больше – все в память – быстрее обработка», а что быстродействие самый актуальный вопрос? Тогда как быть с сохранностью информации (в том числе долгосрочной), а надежностью системы, энергонезависимостью и т.п.

P.S. Наблюдение: архитектура сооружений – отдельная наука, материаловедение – отдельная наука. Находим новый материал, ищем ему применение (т.е. пользу), применяем, изучаем последствия, распространяем…
В перспективе => непредсказуемо: он может со временем вытеснить известные ранее материалы, может занять свою отдельную нишу или исчезнуть, сам замененный чем-либо.

[Recoilme]

Цитата:

Сообщение от macklakov

Вас сильно волнует, как данные хранятся в бэкапе? Ведь рабочие будут в памяти, в виде объектов. В этом вся фишка, что данные не нужно получать и сохранять, они все время под рукой.

Часть, конечно, останется в табличной форме, т.к. это наиболее естественно. К примеру, таблица закзов. Но вот строки заказов, это уже атрибуты самих заказов. А колличество запросов и их сложность резко снизится, т.к. к запросы по связанным таблицам, это скорее исключение.

Гы

[macklakov]

Цитата:

Сообщение от Recoilme

Гы

Еще раз повторяю, что объектные базы, это не более, чем средство для backUp-ов и поэтому сравнивать их с СУБД неправомерно.

[macklakov]

Цитата:

Сообщение от Pavel

Зачем все собирать в кучу, методы хранения информации, методы представления объектов в приложении, способы их технической реализации, пользовательские интерфейсы… а затем все в J2EE и против РБД?

Начнем с того, что серверные компоненты не имеют отношения к пользовательским интерфейсам. А хранение информации они как раз позволяют отвязать от логики. Объекты можно сериализовать как в РБД, так и в ОБД и в XML и в бинарный файл...

Цитата:

Сообщение от Pavel

Не понятна целесообразность такого подхода. Какая преследуется цель? В чем ее практическая ценность?

Те же, что и при переходе с 2-х уровневой на 3-х уровневую аксапту. Кроме того, это позволит отвязать логику и представление данных от способа их хранения

Цитата:

Сообщение от Pavel

«Память будет больше – все в память – быстрее обработка», а что быстродействие самый актуальный вопрос?

Один из ограничивающих. Т.к. из-за быстродействия часто отказываются от многих возможностей.

Цитата:

Сообщение от Pavel

Тогда как быть с сохранностью информации (в том числе долгосрочной)

есть такой термин, "сериализация"

Цитата:

Сообщение от Pavel

а надежностью системы, энергонезависимостью и т.п.

расскажите, что происходит, если обесточить RAID?

Цитата:

Сообщение от Pavel

P.S. Наблюдение: архитектура сооружений – отдельная наука, материаловедение – отдельная наука. Находим новый материал, ищем ему применение (т.е. пользу), применяем, изучаем последствия, распространяем…

Архитектурное решение очень сильно зависит от выбранных материалов Из дерева небоскреб не построишь, а из стали изба тоже не очень хорошая получится

[belugin]

Цитата:

Сообщение от macklakov

Еще раз повторяю, что объектные базы, это не более, чем средство для backUp-ов и поэтому сравнивать их с СУБД неправомерно.

Гы http://www.db4o.com/about/productinformation/datasheet/

[macklakov]

Цитата:

Сообщение от belugin

Гы

А более веские аргументы есть?

[belugin]

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

[macklakov]

Цитата:

Сообщение от belugin

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

Да костыли эти ООБД, потому и мало кто их всерьез воспринимает. Толку поднимать один объект, если за ним потом целая сеть, по ссылкам, потянется? Только для того, чтобы часть сети сохранить на винт, для освобождения памяти, а потом найти, в приемлимое время. Это все равно, как порезать из "длинных" таблиц РБД старые данные и сохранить на отдельный носитель, для экономии места, а при необходимости, обратно закачивать.

[belugin]

Цитата:

Сообщение от macklakov

Толку поднимать один объект, если за ним потом целая сеть, по ссылкам, потянется?

Lazy loading есть даже в hybernate я уж не говорю о динамических языках.

[ibc]

Цитата:

Часть, конечно, останется в табличной форме, т.к. это наиболее естественно. К примеру, таблица закзов. Но вот строки заказов, это уже атрибуты самих заказов. А колличество запросов и их сложность резко снизится, т.к. к запросы по связанным таблицам, это скорее исключение.

Думаю, что 80-90% данных останется в таблицах.
Возможно таблицы можно будет наследовать и переопределять их методы. Таблицы будут объектами.
Если Джава-объекты в озу работают медленнее, чем РБД на ХДД, то ответ в чем хранить данные - в объектах или в таблицах - очевиден!
Хотя, мне лично интересно было бы взглянуть на концепцую учетной системы, реализованную на объектах, а не на таблицах

[macklakov]

Цитата:

Сообщение от ibc

Возможно таблицы можно будет наследовать и переопределять их методы. Таблицы будут объектами.

Ага, все идет к тому, что языки хранимых процедур разовьются до уровня ООП и РБД СУБД постепенно преврятятся в сервера приложений

Цитата:

Сообщение от ibc

Если Джава-объекты в озу работают медленнее, чем РБД на ХДД, то ответ в чем хранить данные - в объектах или в таблицах - очевиден!

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

[belugin]

MS SQL 2k5, если я не ошибаюсь, уже позволяет писать триггеры на .NET языках (правда вряд ли там есть декларативные запросы)

[ibc]

Цитата:

декларативные запросы

Что такое декл. запросы? Примерчик, если не сложно!

[belugin]

я имел ввиду встроенные прямо в C# запросы которые отображаются на SQL пример
можно посомтреть в конце статьи http://www.interact-sw.co.uk/iangblo...xpressiontrees

[ibc]

Ну, я под декларативными запросами понимал запросы на языке ПРОЛОГ

[belugin]

SQL - тоже декларативный

declarative language - definition by dict.die.net