Здравствуйте, pvoid28, Вы писали:

P>Я считаю, что ООП и конкретно С++ очень неплохой способ грамотно выражать свои мысли.
Ух. Я Вам искренне завидую. С++ не люблю давно и прочно, наверное от того, что это был мой второй язык программирования после Basic много-много лет назад.

P>Но вот только этой грамотности нелегко научиться.
Все, чему сложно научиться, скорее всего содержит элемент ненужной сложности. Считаю, что самым верным является как раз самый простой подход к задаче.

P>Научить всех членов команды использовать STL — и то неплохо будет.
Кстати, у STL и ООП ничего общего. Помнится, автор STL сильно не любил ООП. Можно даже ссылочку найти...

Здравствуйте, GlebZ, Вы писали:

GZ>Аналогично, не совсем согласен с автором, особенно с Table-Oriented Programming. Еще одна грыжа, не более того.
Да, автор тоже грешит необъективностью в критике ООП. Хотя многое заставило меня задуматься — мож не стоит так сильно налегать на ООП ? Процедурные решения часто проще и понятнее.

GZ>Посмотрел www.prevayler.org, сильно не дотягивает до нормальной OOCУБД.
Да, основная трабла — принципиальное отстутсвие языка запросов. Можно прикрутить XPATH, но это мне не кажется хорошим выходом. Больше, честно говоря, не знаю, чего там не хватает. Есть какие-то конкретные идеи, чего еще не хватает ? Было бы интересно выслушать.
Но проблема была не в том, что превэйлер не дотягивает до СУБД. В некотором смысле, превэйлер — способ работать с персистентным ООП, т.е. способ работать с объектами, зная что все результаты гарантированно будут сохранены, не более того. Идея здравая. Проблемы начинаются, когда создаешь ОО модель данных. Ты просто ВЫНУЖДЕН каждый объект нумеровать или как-то еще идентифицирровать. Хранить ссылку где-то в какой-нибудь коллекции. По факту выходит еще много заморочек, к модели в общем-то не относящихся, а лишь помогающих с ней работать. Все эти заморочки можно, конечно, автоматихировать (благо, у Питона гора возможностей по поводу интроспекции), но в конечном итоге у меня создалось стойкое впечатление, что я заново изобретаю базу данных. Тогда я имел неосторожность сходить туды: http://www.geocities.com/tablizer/oopbad.htm
и слова автора по поводу reinventing database с таким резонансом отдались в моей душе, что я чуть не поплакал

GZ>Тяжело описать просто то, что в реальном мире сложно устроено. Не надо, это перекладывать на недостатки метода.
Верно, однако обратите внимание на такой момент. Методология вряд ли сделает вещи проще. Но одни методологии (в отличие от других) ДОБАВЯТ сложности, как это часто бывает.
GZ>Я не очень верю, что полноценная база данных может быть написана небольшой группой энтузиастов за короткое время.
Печально, но факт — нам остаются РСУБД


B>>ООП хорошо для "внутреннего" использования, т.е. для работы с внутренними объектами, никак не связанными с объектами реального мира. Например, мой вебсервер является объектом, не имеющим аналогов в реальном мире. Например, подсистема управления транзакциями TransactionLog тоже к реальному миру имеет отдаленное весьма отношение. Т.е. ООП хорошо применять к таким объектам, над которыми мы имеем полную власть, т.е. над теми, которые мы сами придумали и сами изменяем при необходимости. Тогда не возникает такой ситуации, когда иерархия обектов перестает соответсвовать действительности.
GZ>Смотри не ООП, а компонентное программирование. ООП прекрасен внутри компоненты, но не снаружи.
Вот вот, именно это я имел в виду. Вообще применять ООП внутри компонент и только для внутренних нужд. А про всякое моделирование предметной области методами ООП забыть, как о страшном сне.

GZ>PS: Существует достаточно много очень интересных парадигм, о которых все говорят и дивятся. Действительно, очень правильные вещи. Так сказать, двигают науку. Но в коммерции не проходят обычно по двум причинам. 1. Быстрота разработки. 2. Скорость выполнения. И маркетинг здесь не причем.
При чем, но это уже совсем другой вопрос.

Здравствуйте, Borisman2, Вы писали:

AVK>>Какую ссылку? На то что объектные графы плохо ложаться на плоские таблицы? Или о чем ты?
B>Прошу прощения, не могли бы Вы объяснить более развернуто Ваше предыдущее утверждение о наиболее примитивной структуре (плоский список). Я плохо знаком с вопросом, поэтому прошу Вас дать (если возможно) какие-нибудь ссылки по этой теме.

Ты плохо знаком с РСУБД В современной БД единственный способ представления набора данных это таблица, т.е. плоский прямоугольный список. Все остальные структуры эмулируются, из-за чего собственно и возникают проблемы.

B>>>Пожалйста, ссылку на источник такого определения, если можно.
AVK>>Это не определение.
B>Ээээ... опять прошу прощения за непонятность. Где указано, что навигация предполагает наличие курсора? Опять же, я не знаком с таким вопросом.

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

B>Мне всегда казалось что проблема с сетевыми БД вовсе не в их эффективности.

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

B> Если угодно, я могу написать на Питоне (на java чуть дольше, на C# тоже) сетевую БД, причем довольно быстро, и работать она будет весьма эффективно.

Думаю ты ошибаешься . Попробуй сравнить свою БД и промышленный sql-сервер на больших объемах и, скажем, сотне одновременнно работающих пользователей и ты все поймешь сам . И еще провокационный вопрос — какой уровень изоляций поддерживает твоя БД и какая механика разруливания параллельного доступа используется?

B> Могу изложить основной принцип работы, если угодно.

Не надо, я довольно неплохо знаком с современным положением дел в этой области.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Borisman2, Вы писали:

AVK>Ты плохо знаком с РСУБД В современной БД единственный способ представления набора данных это таблица, т.е. плоский прямоугольный список. Все остальные структуры эмулируются, из-за чего собственно и возникают проблемы.
А, теперь понял, что имелось в виду.

AVK>Курсор это текущая позиция. Навигация, насколько я понимаю русский язык, — навигация это определение позиции и направления на поверхности земли. О какой навигации может идти речь, если текущей позиции не существует?
Ладно, мы имеем в виду разные вещи. Я подразумевал навигацию по ссылкам.

AVK>Думаю ты ошибаешься . Попробуй сравнить свою БД и промышленный sql-сервер на больших объемах и, скажем, сотне одновременнно работающих пользователей и ты все поймешь сам . И еще провокационный вопрос — какой уровень изоляций поддерживает твоя БД и какая механика разруливания параллельного доступа используется?
Ой, там все проще в 15 раз. Вся сеть в памяти, операции над ней предварительно сохраняются в лог транзакций. На объемах данных, меньших нескольких Гб работать будет мгновенно. Уровень изоляции не требуется, т.к. транзакции можно и в самом деле последовательно выполнять (все в памяти же...)

AVK>Не надо, я довольно неплохо знаком с современным положением дел в этой области.
Упс. не буду.

Здравствуйте, Borisman2, Вы писали:

AVK>>Курсор это текущая позиция. Навигация, насколько я понимаю русский язык, — навигация это определение позиции и направления на поверхности земли. О какой навигации может идти речь, если текущей позиции не существует?
B>Ладно, мы имеем в виду разные вещи. Я подразумевал навигацию по ссылкам.

Навигацию по ссылкам в XPath? Теперь уже я не понимаю о чем речь.

B>Ой, там все проще в 15 раз. Вся сеть в памяти, операции над ней предварительно сохраняются в лог транзакций. На объемах данных, меньших нескольких Гб работать будет мгновенно. Уровень изоляции не требуется, т.к. транзакции можно и в самом деле последовательно выполнять (все в памяти же...)

Т.е. параллельный доступ вобще отсутствует? Мдя, после этого я бы о быстродействии даже не и заикался бы.

Здравствуйте, Borisman2, Вы писали:

B>Здравствуйте, GlebZ, Вы писали:

GZ>>Аналогично, не совсем согласен с автором, особенно с Table-Oriented Programming. Еще одна грыжа, не более того.
B>Да, автор тоже грешит необъективностью в критике ООП. Хотя многое заставило меня задуматься — мож не стоит так сильно налегать на ООП ? Процедурные решения часто проще и понятнее.

Приведу небольшой пример 1С. Хотя там и не ООП а IDispatch с поздним связыванием, но разработка сложных систем в ней одно удовольствие. За минимум времени, максимум отдачи. Замедление возможно решаеть за счет компиляции.
Но это надстройка над РБД. В любом случае объектное программирование намного продуктивнее (при замедлении выполнения программы где то больше а где то и незначительно).

Здравствуйте, Borisman2, Вы писали:

B>А про всякое моделирование предметной области методами ООП забыть, как о страшном сне.
А каким методом моделировать предметную область лучше? Можно хотябы простейший пример, типа "Вот смотрите, имеетя предметная область. Если замоделировать ее через ОО, получится вот такая лажа, а если сделать вот так ..., то будет счастье"

Здравствуйте, GlebZ, Вы писали:

GZ>ООСУБД содержит не только состояние объектов, но и его поведение.
Хм, а как БД может хранить поведение?

Здравствуйте, Borisman2, Вы писали:

[skip]

Здравая мысль — ООП не универсально. Но мне не понятно откуда утверждения про реальный мир. Какие 3 кита ООП — абстракция, инкапсуляция, полиморфизм. А что есть абстракция — упрощение реального мира, построение модели. ООП работает с моделями, а не с реальным миром (как и все что связанно с разработкой ПО). Отсюда все проблемы любой парадигмы: построенная нами модель неверно или не полно описывает обьекты реального мира. И это только первая часть проблемы... Вторая часть — оценивать согласованность мира и нашей модели можем только мы сами. А если это делает чел. который эту модель и создавал, то оценка выйдет скорее всего предвзятая...

prVovik wrote:

> Здравствуйте, GlebZ, Вы писали:
>
> GZ>ООСУБД содержит не только состояние объектов, но и его поведение.
> Хм, а как БД может хранить поведение?

определение классов может быть пересено в базу

Здравствуйте, prVovik, Вы писали:
GZ>>ООСУБД содержит не только состояние объектов, но и его поведение.
V>Хм, а как БД может хранить поведение?
при помощи первых двух букв своей аббревиатуры.
З.Ы. современные РСУБД тоже хранят поведение. RTFM по stored procedure & trigger

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Borisman2, Вы писали:

AVK>Навигацию по ссылкам в XPath? Теперь уже я не понимаю о чем речь.
В XPATH шаблон (ну или часть шаблонаб если более точно) задается ссылками. Ладно, кажется мы зашли в тупик, потому что я, похоже говорю о том, чего не очень понимаю. Не знаю я точного определения навигационной БД и сетевой БД и чем они друг от друга отличаются тоже слабо представляю. Я и просил просветить меня в этом плане.

AVK>Т.е. параллельный доступ вобще отсутствует? Мдя, после этого я бы о быстродействии даже не и заикался бы.
А вот тут уже батенька Вы говорите о том, чего не очень понимаете. Давайте на этом пока и закончим или вынесем в отдельную тему.

Здравствуйте, AndrewVK, Вы писали:

Эх.... все же не удержусь и прокомментирую.

AVK>Т.е. параллельный доступ вобще отсутствует? Мдя, после этого я бы о быстродействии даже не и заикался бы.
Внимательно надо читать www.prevazler.org.

Параллельная работа нужна тогда, когда отдельная пользовательская транзакция выполняется ОЧ долго. Это, в частности, происходит тогда, когда надо с винта читать и писать МНОГО.

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

Огромное преимущество такой организации БД — потрясающая, просто ошеломляющая скорость. Т.е. превэйлер-образная БД работает как минимум в 1000 раз быстрее, чем обычная РСУБД.

НУ есть, конечно и затыки свои (а где их нет?). Если интересно, напишу.

Здравствуйте, Borisman2, Вы писали:

B>Параллельная работа нужна тогда, когда отдельная пользовательская транзакция выполняется ОЧ долго. Это, в частности, происходит тогда, когда надо с винта читать и писать МНОГО.

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

B>В нашем случае

В вашем это каком?

B> (когда все объекты в памяти) большинство транзакций (даже самых сложных) выполняются в считанные милисекунды (и даже в микросекунды), а посему распараллеливать транзакции совершенно не нужно.

B>Огромное преимущество такой организации БД — потрясающая, просто ошеломляющая скорость. Т.е. превэйлер-образная БД работает как минимум в 1000 раз быстрее, чем обычная РСУБД.

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

Sinclair,

Позволю себе небольшое уточнение.

> B> Это малость странный подход, который рот не поворачивается назвать ООП.

> И совершенно напрасно не поворачивается. JavaScript устроен именно так, только немношко побогаче. Не факт, что он есмь спасение для бизнес-задач, но это не отменяет его объектности.

Именно объектности. Объектно-ориентированным JavaScript не является. Но, естественно, не из-за того, что в нем есть упомянутая функциональность.

Здравствуйте, Sinclair, Вы писали:

Извиняюсь, за задержку с ответом, очень много было работы.
S>Здравствуйте, GlebZ, Вы писали:

GZ>>2. Для сторед процедур можно построить и сохранить планы выполнения.
S>Верно, с оговорками. А как же if? а циклы?
А никак. В комерческих РСУБД важны только планы выполнения и зависимости. Или есть другие механизмы?
GZ>>Если запрошена проперть у ООСУБД, нельзя точно спрогнозировать что она для себя потребует в процессе выполнения.
S>Почему это невозможно?
GZ>>Внутренняя логика метода, со всеми if'ами и switch'ами, наследованием, перекрестными вызовами, может быть достаточно сложна для этого.
S>Хм. На первый взгляд, ничего сверхъестественного.
С вашим подходом, возможно. У меня была задумка сделать все без зависимости от языка программирования. И MSIL тогда был только в проекте.
GZ>> Для этого отслеживают статистику, что было запрошено при выполнении этой проперти в прошлые разы.
S>А это кто например? Можно ссылку на ООСУБД, которая это умеет?
Источник, какая-то книга по теории баз данных. Точно сказать не могу (давно этим увлекался), возможно даже Дейт.
Система, остлеживает выполнение, и по мере накопления статистики строит или перестраивает планы. То есть, пытается делать то же самое что в РСУБД. Вы похоже пошли значительно дальше.

S>Уже сейчас очевидно, что далеко не во всех случаях можно будет получить 100% оптимальный план запроса. Основные заметные препятствия — рекурсия/циклы и исключения.
S>То есть вряд ли удастся привести предикат вида
S>

S>Factorial(self.Salary)<120
S>

S>к предикату вида
S>

S>self._salary < 5
S>

S>А это, в свою очередь, не даст использовать индекс. Но лично мне греет душу смутное ощущение, что факториалы применяются в реальном софте, ворочающем гигабайтами, очень редко. И что в практических случаях из запроса удастся выделить предикат, достаточно селективный для того, чтобы снизить стоимость выполнения запроса до приемлемой.

S>Ну вот С++ тоже далеко не всегда может вполнить инлайнинг; тем не менее, его включение во многих случаях приводит к заметному росту производительности. Например, насколько мне известно, STL весьма чувствителен к поддержке инлайнинга, т.к. его применение очень много где из кучи взаимных вызовов и проверок сворачивается, грубо говоря, в rep stosd.

Круто. Где-то это я уже читал и тогда мне это не понравилось. Но сейчас весьма круто. Тогда не особо поверилось, что такое возможно (грешен, субъективен, не особо понимал вся прелесть байт-кода). Во многих случаях получить селективный предикат будет невозможно. По крайней мере, как это сделать с рекурсией я не догадался. Я бы еще прибавил ограничение — если существует 3 различных переменные в одном составном операторе, позднее связывание. Процентов 80-90 пропертей достаточны элементарны и данный метод их сократить. Правда при этом нужно будет реализовывать вычисление всего что можно предварительно вычислить (что мне кажется очень полезной но несколько сложноватой задачей, хотя и не невозможной).

С уважением, Gleb.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Borisman2, Вы писали:

B>>Параллельная работа нужна тогда, когда отдельная пользовательская транзакция выполняется ОЧ долго. Это, в частности, происходит тогда, когда надо с винта читать и писать МНОГО.
AVK>Она нужна во многих случаях. Иначе бы на это производители современных СУБД не убивали столько сил. И дело даже не столько в паралдлельной работе, сколько в обеспечении уровня изоляции.
Уровни изоляции нужны для того, чтобы симулировать последовательное выполнение транзакций в системе, где транзакции проходят параллельно. Самый лучший уровень изоляции — SERIALIZED, т.е. когда выполнение транзакций неотличимо от последовательного. Все остальные уровни изоляции — компромисс между скоростью и надежностью. Когда транзакции НА САМОМ ДЕЛЕ идут последовательно, все эти заморочки не нужны.

B>> (когда все объекты в памяти) большинство транзакций (даже самых сложных) выполняются в считанные милисекунды (и даже в микросекунды), а посему распараллеливать транзакции совершенно не нужно.
B>>Огромное преимущество такой организации БД — потрясающая, просто ошеломляющая скорость. Т.е. превэйлер-образная БД работает как минимум в 1000 раз быстрее, чем обычная РСУБД.
AVK>На игрушечных задачах. Пойми, длительность транзакции определяется предметной областью, а не разработчиком БД.
Можно ли назвать игрушучной задачу, которая работает со сложной структурой данных, занимающей до 1Гб ? У меня язык не поворачивается. Есть у меня такая задача, написанная под РСУБД — так запросы там очень не быстро ворочаются. Прямой кандидат на перенос под Превэйлер.
Как и у любого средства, у превэйлер-баз есть своя область применения. Они не универсальны. Они очень хорошо должны решать задачи, где объем данных не превышает объема ОЗУ. Задачи бОльшего объема они решать не могут.

К тому же, за все надо платить.
Одно из действительно неприятных (ну, по крайней мере, очень непривычных) свойств таких бд состоит в том, что запросы в БД по сути являются частью БД и имеют над ней полную власть. Т.е. надо очень хорошо думать, какие запросы писать — а то порушить можно все за считанные микросекунды . Выражаясь словами изобретателей концепции, Вы больше не пишете клиентский код. Вы тепер ьпишете серверный код и должны точно знать, что делаете.

Второе неприятное свойство таких БД (я уже по-моему, говорил) — нет языка запросов в принципе. Можно, конечно, прикрутить XPATH и это решит проблему.

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

Ну еще есть куча заморочек, связанных с ООБД вообще. Например, привязка к конкретному языку.

Здравствуйте, Borisman2, Вы писали:

AVK>>На игрушечных задачах. Пойми, длительность транзакции определяется предметной областью, а не разработчиком БД.
B>Можно ли назвать игрушучной задачу, которая работает со сложной структурой данных, занимающей до 1Гб ?

Можно. 1Гб по нынешним временам детский объем, так что это не показатель (у януса примерно такой порядок БД, а там банальный джет). Тяжесть задач выражается не столько в сложных структурах данных, сколько в требованиях по скорости реакции, способности выполнять сложные выборки, обслуживать десятки и сотни запросов одновременно, при том что единичная транзакция может быть довольно длительной. А если у тебя десяток пользователей, то конечно можно и отказаться от параллельного выполнения.

B> У меня язык не поворачивается. Есть у меня такая задача, написанная под РСУБД — так запросы там очень не быстро ворочаются.

А сколько клиентов одновременно работают с базой?

B>Одно из действительно неприятных (ну, по крайней мере, очень непривычных) свойств таких бд состоит в том, что запросы в БД по сути являются частью БД и имеют над ней полную власть. Т.е. надо очень хорошо думать, какие запросы писать — а то порушить можно все за считанные микросекунды .

При современных требованиях звучит как приговор.

Здравствуйте, Borisman2, Вы писали:

B>Здравствуйте, GlebZ, Вы писали:

GZ>>Аналогично, не совсем согласен с автором, особенно с Table-Oriented Programming. Еще одна грыжа, не более того.
B>Да, автор тоже грешит необъективностью в критике ООП. Хотя многое заставило меня задуматься — мож не стоит так сильно налегать на ООП ? Процедурные решения часто проще и понятнее.
Если у тебя написано кода на пол-гига и с ним работает человек двадцать, то о процедурном решении можно забыть.

GZ>>Посмотрел www.prevayler.org, сильно не дотягивает до нормальной OOCУБД.
B>Да, основная трабла — принципиальное отстутсвие языка запросов. Можно прикрутить XPATH, но это мне не кажется хорошим выходом. Больше, честно говоря, не знаю, чего там не хватает. Есть какие-то конкретные идеи, чего еще не хватает ? Было бы интересно выслушать.
B>Но проблема была не в том, что превэйлер не дотягивает до СУБД. В некотором смысле, превэйлер — способ работать с персистентным ООП, т.е. способ работать с объектами, зная что все результаты гарантированно будут сохранены, не более того. Идея здравая. Проблемы начинаются, когда создаешь ОО модель данных. Ты просто ВЫНУЖДЕН каждый объект нумеровать или как-то еще идентифицирровать. Хранить ссылку где-то в какой-нибудь коллекции. По факту выходит еще много заморочек, к модели в общем-то не относящихся, а лишь помогающих с ней работать. Все эти заморочки можно, конечно, автоматихировать (благо, у Питона гора возможностей по поводу интроспекции), но в конечном итоге у меня создалось стойкое впечатление, что я заново изобретаю базу данных. Тогда я имел неосторожность сходить туды: http://www.geocities.com/tablizer/oopbad.htm
B>и слова автора по поводу reinventing database с таким резонансом отдались в моей душе, что я чуть не поплакал
Вы наткнулись как раз на то, что ООСУБД, просто обязана делать, а именно иметь язык запросов. То что можно обойтись просто навигационным доступом это миф, я сам на это как-то наткнулся. Насчет хранении ссылки, то здесь все верно, если время жизни объекта зависит от существовании ссылки. При правильном подходе, эту методику можно очень красиво использовать. В действительности, еще хотелось бы иметь классификацию ссылок, и определение логически удаленного объекта.
Еще хотелось бы сказать об OID и почему я назвал его наиболее ценным в концепции OID. (Ессно мое субъективное мнение)
1. Не стоит его сравнивать с ассоциативным доступом в РСУБД. OID не является ключом к объекту. Скорее он похож на указатель. То есть, для того, чтобы получить доступ к объекту не надо искать его в индексе, как это сделано в РСУБД. За счет этого, утверждается, что для распределенных (сильно нормализованных) объектов, объектно-ориентированные СУБД работают значительно быстрее.
2. Формально (насколько я помню манифест ООБД) OID является просто идентификатором. Фактически это путь к объекту, то есть СЕРВЕР.БАЗА.ТИП.ОБЪЕКТ (по крайней мере, он должен быть таким, хотя бы на уровне логического OID). Таким образом, имея идентификатор, можно забыть о том, где находится объект. У тебя есть только система, и OID. Это вполне достаточно для его получения, независимо от того, где он находится в системе (на каком сервере, в какой БД и независимо от типа).
3. Насчет идентификации через OID. Согласно манифесту OID идентифицирует объект как во время его жизни, так и после. То есть, не может существовать два одинаковых OID. Для РСУБД это нормальная ситуация, и очень забавно смотреть, что когда продукт вырастает до распределенного, народ начинает придумывать дополнительные, глобально уникальные, ключи или процедуры маршализации.
4. OID может сразу содержать тип объекта. Таким образом, если у объекта есть ссылка на другой объект, то этот другой объект, не обязательно должен быть одного предопределенного типа или наследоваться от него. Безусловно, некоторая логика должна ограничивать возможный тип объекта, но радует сам факт. (При доступе по ключу, в РСУБД, это нормальная ситуация, для ООП нет). Когда-то, когда я интересовался этим вопросом, сделал прототипчик. Методика работала на ура.

GZ>>Тяжело описать просто то, что в реальном мире сложно устроено. Не надо, это перекладывать на недостатки метода.
B>Верно, однако обратите внимание на такой момент. Методология вряд ли сделает вещи проще. Но одни методологии (в отличие от других) ДОБАВЯТ сложности, как это часто бывает.
Я бы сказал не сложности, а количества выполняемой работы. Как сказал Черчиль: "Демократия очень плохой способ управления государством, но я не знаю лучшей альтернативы"(дословно не помню, написал по смыслу). Методология проектирования (RUP, MSF), обычно утверждает, что определив свойства и действия, мы можем определить используемые объекты. Точно-так же как и реале. Человеческий мозг идентифицирует объекты по свойствам. Например: пиво — бутылка, темная жидкость с пузырьками, его можно пить, на нем написано "ПИВО" и т.д. и т.п. Подобных свойств или признаков, очень много, чтобы человек мог идентифицировать, что это есть пиво. В программировании, мы всегда описываем только те свойства, которые нам нужны. Поэтому, в жизни сложность объекта в значительной степени выше, чем мы используем. Новые свойства добавить не сложно, если бы не одно но. Человеку свойственно лениться и делать ошибки. Для того, чтобы реализовать свойство, они выделяются в отдельные объект и привязывается к различным типам объектов. В результате, меньше работы, и меньшая вероятность копирования ошибок. Плата за это — неясность является свойство для данного объекта, абсолютно точно таким, как и для другого объекта. То есть, это уже меньше похоже на реал, но действительно сокращает количество работы и весьма возможно получить проблемы при использовании. ООП, или компоненты, все таки очень похожи на объекты в жизни, но не одинаковы, поскольку сильно упрощены. А теперь, представь себе, как это все описать в процедурном программировании? И в особенности если в программе должны ориентироваться n количество программистов. ООП и компоненты дают описание самой программы и действий в единых терминах как для пользователя так и для программиста. С процедурным программирование, это сделать значительно сложнее.

GZ>>Я не очень верю, что полноценная база данных может быть написана небольшой группой энтузиастов за короткое время.
B>Печально, но факт — нам остаются РСУБД
На мой взгляд, РСУБД это место хранения состояния объектов с возможностями доступа к ним. Ни более того. Таким его и пользую, пока не мешает. Появится OOБД который сможет сохранять объекты более эффективно, буду пользовать его. Вообще, я не считаю что при появлении успешной ООБД, произойдет огромный качественный скачок в программировании, но то что это будет большим плюсом, уверен.

B>Вот вот, именно это я имел в виду. Вообще применять ООП внутри компонент и только для внутренних нужд. А про всякое моделирование предметной области методами ООП забыть, как о страшном сне.
А можно спросить, в чем разница в моделировании предметной области методами ООП и компонент? Мне кажется, что компонент. программирование, — ограниченное применение ООП. Разница — только в системе публикации интерфейса.

С уважением, Gleb.