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

[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. я согласен с вами только в той мысли, что идет смена технологий и платформ. СУБД все больше скрывается от пользователя и даже разработчика за фасадом новых интерфейсов, объектами разных технологий и способов интеграции бизнес приложений на уровне абстракций.

[macklakov]

Цитата:

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

Аксапта со своими средствами разработок не избавилась от триггеров, форм, запросов и прочих элементов СУБД. Что не позволяет противопоставлять ООП и РБД. Не согласны?
Полагаете аксапта с ООП избавилась от всего выше перечисленного?

Для начала повторюсь, что аксапта реализует лишь некоторые аспекты ООП. А от хранения данных в СУБД невозможно отказаться, пока память медленная и ограничивается 4ГГб. Хотя, AOS пытается это делать.

Цитата:

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

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

Простите, мы об одном и том же говорим? Я говорю о реляционной алгебре.

Цитата:

Сообщение от http://www.3ka.mipt.ru/vlib/citforum/database/dblearn/dblearn02.shtml

Основы реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г.

[Pavel]

Цитата:

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

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

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

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

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

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

[Pavel]

Цитата:

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

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

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

[Gustav]

Мне когда-то запала в душу такая цитата:

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

(Д.П.Мак-Манус. Обработка баз данных на Visual Basic 6 - СПб, Вильямс, 1999 - стр.374, 3-й абзац сверху)

[Pavel]

Цитата:

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

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

У каждого способа хранения информации есть свои особенности (не стал бы их называть преимуществами и недостатками), которыми в определенных условиях можно воспользоваться.

Например, в студенческие времена решал задачу идентификации в полупроводниковых кристаллах электрических схем (программа была С++). Кристалл описывался трехмерной матрицей (сечения по осям координат), а его электрическая схема сохранялась в неоднородном списке. Матрицу удобно хранить и обрабатывать в РБД, а электрическую схему - в виде связанных списком объектов.

[macklakov]

Цитата:

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

У каждого способа хранения информации есть свои особенности (не стал бы их называть преимуществами и недостатками), которыми в определенных условиях можно воспользоваться.

Ключевое слово ХРАНЕНИЕ. Именно поэтому мы не можем понять точку зрения дург друга. В РБД данные удобно ХРАНИТЬ, а потом быстро ИСКАТЬ, а в ООП удобно ОБРАБАТЫВАТЬ, т.к. данные и способ их обработки связаны между собой и структуры данных не ограничены реляционной моделью, хотя и могут ее реализовывать.
Что касается темы обсуждения, то мое мнение такое: использование ООП слабо согласуется с ERP, т.к. основная цель языка все же ограничить прикладного разработчика
Реальную технологическую выгоду от использования ООП можено было бы получить при использовании бизнес-копонент, написанных, на полноцнных языках, из которых можно было бы составлять свои системы. Но IMHO продажа таких компонент не даст тех прибылей, кторые дает комплексное внедрение

OFFTOP

Цитата:

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

в студенческие времена решал задачу идентификации в полупроводниковых кристаллах электрических схем

Ай как нехорошо! Это же форменное пиратство!

[Recoilme]

Цитата:

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

Мне когда-то запала в душу такая цитата:

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

(Д.П.Мак-Манус. Обработка баз данных на Visual Basic 6 - СПб, Вильямс, 1999 - стр.374, 3-й абзац сверху)

Статья Тенцера, описывающая на небольшом примере: "как именно можно вставить круглый колышек в квадратную БД"
сцылка
ЗЫ: имхо - это уже мегапроктология