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

[ibc]

Цитата:

Не сильно облегчает, т.к. не является полноценным ООП.

Наличие полноценного ООП, т.е. наследования таблиц и др. объектов очевидно в ближайшем будущем ожидать не следует...

Цитата:

в сочетании со сложной иерархией

А, что по вашему мнению АОТ можно было бы упростить?

[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-й абзац сверху)

[ibc]

Цитата:

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

Угу! Но если в качестве объекта будет ВСЯ таблица со всеми записями?
Ася?

[mit]

как раз таблица вписывается в объектную модель. автор видимо имеет ввиду именно запись, причем полученную путем выборки из нескольких таблиц, связь 1:н. поправьте, если не прав.

[Pavel]

Цитата:

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

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

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

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

[macklakov]

Цитата:

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

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

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

OFFTOP

Цитата:

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

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

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

[Pavel]

Цитата:

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

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

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

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

[macklakov]

Жуткий OFFTOP

Цитата:

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

- синтез кристаллов по ограничениям конкретной технологии
- экстрация электрических схем
- схемотехнический анализ эл.схемы и идентификация логических функций

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

[Recoilme]

Цитата:

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

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

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

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

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

[Recoilme]

Вот ещё очень верное, на мой взгляд, определение ООП:

Цитата:

Соответственно считается, что "граблеперенесение" повысит качество и надежность ПО

взято тут:
http://sql.ru/forum/actualthread.aspx?tid=262026&hl=net

[Recoilme]

Наткнулся, тут... прям неудержался от цитаты))) :

Цитата:

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

Пол Грэм, Языки программирования через сто лет

[Gustav]

Цитата:

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

Наткнулся, тут... прям неудержался от цитаты)))

Душевно.
Да там уже прямо с самого начала увлекательно:

Цитата:

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

Я считаю, что похожая судьба ждёт и Джаву. Люди спрашивают меня: "Как можно говорить, что Джаве не быть? Она уже стала успешным языком". И я не могу не согласиться с ними. Джава - успешный язык, если считать мерилом успеха площадь полок с учебниками Джавы в книжных магазинах или количество студентов, убеждённых, что знание Джавы поможет им найти работу. Я имел в виду другое. Мне кажется, Джава окажется таким же эволюционным тупиком, как Кобол.

П.Грэм. Языки программирования через сто лет

[eugene egorov]

Йоды магистра речи тайна открыта. Оказывается на фортране программист старый есть он.

[Recoilme]

Цитата:

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

Душевно.

Ага, меня тоже радует он (сорри первым язагом был фортран )))..
Ещё чтоб погреть тебе сердце:

Цитата:

Я где-то читал, что язык Java не так давно стал самым популярным инструментом программирования, опередив по популярности "Кобол". Для языка, как стандарта, это, безусловно, большой успех. Но в качестве среды для творчества языку Java еще есть, к чему стремиться. Из всех знакомых мне выдающихся программистов я знаю только одного человека, который добровольно выбрал бы язык Java для работы. Да и то, в связи с тем, что этот человек работает в фирме Sun Microsystems.

И специально для тебя - небольшоя подборочка:
http://webradar.ru/

[Maximin]

Спор ни о чём. Технология ради технологии никому не нужна.
Взять тот же процессор i860. Замечательный проц, куча новых технологий.
И где он? Где те же Itanium? Весь мир до сих пор сидит на x86, ибо пока он устраивает всех. Правда, от оригинального x86 всё меньше и меньше остается.

Что касается ODB - как только РЕЗКО появятся такие задачи, которые нельзя будет решить на РДБ - так они и пойдут в рост. А так - классические РДБ будут и дальше обрастать объектно-подобной мишурой. Или пока кто-нибудь не придумает некий подход, который объединит обе концепции в единую новую.