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

macklakov · 19.01.2006, 15:18

Цитата:

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

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

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

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

Pavel · 19.01.2006, 16:36

Цитата:

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

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

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

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

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

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

macklakov · 19.01.2006, 17:46

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

Архитектурное решение очень сильно зависит от выбранных материалов

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

belugin · 19.01.2006, 19:25

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

macklakov · 19.01.2006, 19:36

Цитата:

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

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

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

belugin · 19.01.2006, 19:57

Цитата:

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

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

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

ibc · 20.01.2006, 11:20

Цитата:

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

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

macklakov · 20.01.2006, 15:46

Цитата:

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

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

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

Цитата:

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

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

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

belugin · 20.01.2006, 16:53

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

ibc · 20.01.2006, 17:47

Цитата:

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

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

belugin · 20.01.2006, 19:59

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

ibc · 23.01.2006, 10:12

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

belugin · 23.01.2006, 12:34

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

declarative language - definition by dict.die.net

ibc · 24.01.2006, 12:44

Цитата:

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

от того, что SQL засунули в C#, он (SQL) не стал более декларативным!

macklakov · 24.01.2006, 17:26

Цитата:

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

от того, что SQL засунули в C#, он (SQL) не стал более декларативным!

В него засунули не SQL, а LINQ, который является практически самостоятельным функциональным языком, и попадает под понятие декларативного. А псевдо-SQL в нем имеет такое же отношение к SQL, как С# к С++.

belugin · 24.01.2006, 17:03

да, C# стал

**Андре** · 24.01.2006, 17:30

Цитата:

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

Не стоит путать декларативные запросы и декларативные языки программирования.

Цитата:

от того, что SQL засунули в C#, он (SQL) не стал более декларативным!

Цитата:

да, C# стал

Можно и так сказать. По крайне мере в С# 3.0 введен синтаксис лямбд и в некоторой степени continuation (в виде yield return). Где-то на rsdn.ru VLAD2 показывал пример ленивого вычисления на С#, но это уже как-то за уши притянуто.

ibc · 24.01.2006, 18:01

Цитата:

но это уже как-то за уши притянуто.

LISP?

Цитата:

Не стоит путать декларативные запросы и декларативные языки программирования.

В ПРОЛОГ-е есть запрос 1 - в конце программы - это и есть декларативный запрос! :P

**Андре** · 24.01.2006, 18:17

Цитата:

LISP?

Что Lisp? Я вообще про С# писал выше.
Если это пример декларативного языка программирования - то, да, в некоторой степени. Из последних и популярных:

* Erlang (довольно успешный в коммерческих разработках - все последние телекомовские проекты Ericsson, Synapse - GSM решения). На мой взгляд самый простой и идеально подходит для знакомства с концепциями.
* Hackel - недавно начал разбираться, поэтому многое не скажу. Очень понравились ленивые вычисления.
* O'Calm - не смотрел, но знаю что люди используют.

Lisp часто ругают за то, что он, хотя и основан на функциональных идеях, содержит много императивного.

**mazzy** · 24.01.2006, 18:26

Скажите, пожалуйста, участники дискуссии:
есть ли шанс, что ваше обсуждение вернется к Dynamics-системам?
или стоит перенести тему в курилку?

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
ERP-системы — мэйнстрим или тупиковая ветвь?	slava09	Курилка	30	26.09.2010 18:00
Консультант по внедрению ERP-систем 250 тыс. р.	miklenew	Курилка	4	13.01.2009 23:30
Встреча специалистов по внедрению ERP и CRM систем в клубе "Пегас" 5 декабря 2008 года	George Nordic	Курилка	90	09.12.2008 00:45
Практика подготовки к внедрению ERP-систем	slava09	Курилка	4	08.10.2008 11:29
Встреча ИТ-специалистов в области ERP-систем в г. Москва 12 августа 2005г.	George Nordic	Курилка	115	21.09.2005 10:17