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

[Тимур]

Ну да. Понятно. Русских кулибиных не истребить. Даже если денег не платить.
Хочется услышать об уже давно работающих ERP-системах.

[belugin]

>>>скажите, плиз, а вы знаете хотя бы одну ERP-систему, которая была разработана с использованием ООП?

По-моему, при разработке Аксапты оно немного использовалась. В принципе, таблицы в Axapte есть объекты в стиле старых версий VB (кажется, в книжке Буча табие языки назывались объектными в отличие от объектно-ориентированных)

А вообще интересно будет, когда либо появятся объектные СУБД либо ОО-языки станут более декларативными и будут лучше отображаться на RDBMS (Например, вот что пытается сделать MS).



Сейчас все большую популярность приобретают средства такого отображения. Например сейчас много шуму наделал Ruby on Rails, который включает в себя средство отображения объектов на СУБД и в вебинтерфейс.

ERP (по крайней мере известные мне) конечно штуки заскорузлые в плане технологии, но и до них это когда-нибудь долезет.

[Тимур]

А зачем искусство ради искусства? Кто будет платить за "банкет"?

[belugin]

зачем ООП вообще? зачем отображение на РБД?

[macklakov]

Цитата:

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

зачем ООП вообще? зачем отображение на РБД?

Затем, что главное назначение РБД, быстрый доступ к данным на МАГНИТНОМ носителе. Но с 64-х разрядной архитектурой, можно будет всю базу держать в оперативной памяти, а сохранение на диск будет аналогом бэкапа. Соответственно, реляционное представление данных должно потерять свою актуальность, данные и способы обработки станут более приближенными к предметной деятельности. А ООП, хороший способ их систематизировать.
Хотя, конечно, эмуляции РБД (вроде аксаптовских tmpTable и dataSource), продолжат существование, т.к. слишком много народу привыкло мыслить этими категориями.

[simply2double]

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

Кстати тема дискуссии вообще непонятна. Какой смысл ломать копья, выясняя чей ООП круче... типа футбол лучше волейбола.. потому что, там можно по мячику ногами лупить...
ООП в аксе такое, какое есть. И без него было бы вообще тухло.

Поэтому хватит базарить, идите программируйте

[Pavel]

Цитата:

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

Затем, что главное назначение РБД, быстрый доступ к данным на МАГНИТНОМ носителе. Но с 64-х разрядной архитектурой, можно будет всю базу держать в оперативной памяти, а сохранение на диск будет аналогом бэкапа. Соответственно, реляционное представление данных должно потерять свою актуальность, данные и способы обработки станут более приближенными к предметной деятельности. А ООП, хороший способ их систематизировать.

Оригинально. Табличную форму хранения информации человек использовал задолго до появления терминов СУБД, ООП... вряд ли она потеряет свою актуальность при изменении разрядности процессоров (64-х, 128-ми и т.д.). Нормированные таблички - это математика, а разрядность вычислительной архитектуры - степень возможности человека материализовать математику в своих технологиях.

[macklakov]

Цитата:

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

Оригинально. Табличную форму хранения информации человек использовал задолго до появления терминов СУБД, ООП...

Да, но так же он придумал много других абстрактных конструкций, а мы вынуждены сводить их к реляционным сущностям. К примеру, более древними, чем табличные, являются иерархические структуры, а ассоциативные, вообще отражают способ хранения данных в нашем мозгу. Да, найдены способы реализации большинства из этих конструкций в РБД, но это приводит к тому, что бОльшая часть сущностей заводится исключительно для служебных целей.

Цитата:

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

Нормированные таблички - это математика

Если не ошибаюсь, этой математике порядка 30-40 лет и создавалась она под конкретную задачу.

Цитата:

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

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

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

[Pavel]

Цитата:

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

Если не ошибаюсь, этой математике порядка 30-40 лет и создавалась она под конкретную задачу.

"ЛАТИНСКИЙ КВАДРАТ, квадратная таблица n2 чисел, каждая строка и каждый столбец которой содержат числа 1, 2,..., n. Напр., для n = 3
2 3 1
3 1 2
1 2 3
Латинские квадраты применяются в комбинаторике.

ЛЕГИОН, в древнерусском счете 100 тыс.

ЛЕЖАНДРА МНОГОЧЛЕНЫ, специальная система многочленов, ортогональных с весом 1 на отрезке [-1;1]. Рассматривались А. Лежандром и П. Лапласом (в 1782-85)."
http://mathforall.narod.ru/formuls/1.10.htm

Для себя поинтересовался историей данного вопроса... однако, не менее двух столетий.

Цитата:

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

Хотя, наверное, для Вас мои слова звучат как ересь, особенно, если учесть, что SAP появился благодаря появлению РБД, а появление РБД было вызвано в первую очередь учетными системами...

Кроме SAP у меня еще девять лет опыта работы с продуктами MBS.
Поддерживаю вашу мысль, прикладные языки XAL (Конкорд от Damgaard), C/AL (Navision) из семейства 4GL являются интерфейсами к РБД или тем, что называют СУБД. Аксапта со своими средствами разработок не избавилась от триггеров, форм, запросов и прочих элементов СУБД. Что не позволяет противопоставлять ООП и РБД. Не согласны?

Цитата:

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

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

Полагаете аксапта с ООП избавилась от всего выше перечисленного?

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

[Pavel]

Цитата:

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

Затем, что главное назначение РБД, быстрый доступ к данным на МАГНИТНОМ носителе. Но с 64-х разрядной архитектурой, можно будет всю базу держать в оперативной памяти, а сохранение на диск будет аналогом бэкапа.

Если следовать информации из новостной ленты, то СУБД в памяти уже реальность и имеет коммерческое использование.

"Краткая характеристика СУБД TimesTen состоит в том, что за счет хранения баз данных целиком в основной памяти и соответствующей оптимизации структур хранения и индексирования система обеспечивает очень высокую производительности (в десять раз превосходящую производительность традиционных СУБД) при выполнении операций выборки из базы данных. В типичном сценарии использования TimesTen база данных целиком загружается в основную память с дисков при старте системы, и все операции над базой данных выполняются без обращения к дискам."
подробности здесь - http://citcity.ru/11418/

Цитата:

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

Соответственно, реляционное представление данных должно потерять свою актуальность, данные и способы обработки станут более приближенными к предметной деятельности. А ООП, хороший способ их систематизировать.

Ничего этого нет, абсолютно классическое построение СУБД и в 32-х и в 64-х битном исполнении.

[macklakov]

Цитата:

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

Ничего этого нет, абсолютно классическое построение СУБД и в 32-х и в 64-х битном исполнении.

В данном продукте нет, но в других продуктах будут и нереляционные структуры использоваться. Да и реляционные сущности уже начинают превращаться в классы с объектами-записями, т.к. на них навешано слишком много кода.

[Pavel]

Цитата:

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

В данном продукте нет, но в других продуктах будут и нереляционные структуры использоваться. Да и реляционные сущности уже начинают превращаться в классы с объектами-записями, т.к. на них навешано слишком много кода.

Всего лишь конкретный пример.
Возможно, он и не определяет путей стратегического развития БД, но в пределах нашей теоретической дискуссии не помешает немного конкретики и фактов из жизни.

[skof]

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

[belugin]

вы пытались работать с ООСУБД?

[ibc]

Цитата:

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

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

[macklakov]

Цитата:

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

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

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

Цитата:

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

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

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

[Recoilme]

Цитата:

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

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

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

Гы

[macklakov]

Цитата:

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

Гы

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

[belugin]

Цитата:

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

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

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

[ibc]

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