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

[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

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

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

[Pavel]

Цитата:

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

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

Обычная реакция с которой приходилось сталкиваться на всякого рода научных конференциях.

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

[Recoilme]

Цитата:

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

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

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

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

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