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


B>Короче идея в том, чтобы объекты представлять в виде маппингов имя атрибута->атрибут
B>А методы к ним можно применять какие хошь...

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

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

B>Где бы найти self для Windows ????

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

MN>>Объекты не могут изменить свой тип, потому что у них его просто нет, но они могут на в процессе исполнения программы менять свой функционал и структуру (эволюционировать или деградировать), могут менять своих предков. И всё это находится в рамках объектно-ориентированой парадигмы, с одной стороны, и помогает реализовать "многоклассовость" мира с другой.
B>Интересная концепция. Однако, в такой постановке понятие класса и объекта настолько размывается, что лично мне вообще становится трудн оего увидеть.

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

B>Экстент — это, грубо говоря, список всех объектов заданного типа(класса).
Спасибо, буду знать .

MN>>Согласен с одним дополнением. Когда "действительность" смоделирована — взаимодействующие сущности выделены, их атрибуты, используемые в программе определены, отношения запротоколированы — никто не мешает построить по этой модели объектно-ориентированную, которая будет применяться непосредственно для разработки.
B>Никогда действительность до конца не будет смоделирована. Завтра придет босс и скажет — а ну-ка Семен Семеныч, сделай-ка нам вот так и вот эдак...
B>Вопрос о том, что модель когда-то будет соответствовать действительности вообще не стоит. Не будет. Вопрос стоит так: какой подход гибче, какой подход легче модифицировать? Мне кажется, реляционную модель легче изменить, потому что она проще.

Вот тут согласен. Хорошо спроектированная ООП-модель как правило очень хорошо описывает текущую реальность, но очень плохо подаётся модификации.
С другой стороны я натыкался на ситуации, даже когда реляционная модель давала сбои. Из личного опыта:
один раз передо мной встала задача модификации одной бухгалтерской программы (по-моему складской учёт или что-то в этом роде); программа писалась не мной, мне понадобилось только внести небольшое изменение в ту часть, которая занималась генерацией отчётов, в связи с изменением в налоговом законодательстве — изменился порядок расчёта какого-то налога, изменение в законе было небольшим, первая модификация базы была не существенна, но дабы сохранить обратную совместимость и не вносить существенные изменения в код пришлось поизвращаться... но после следующих 5 подобных измениний (опять законы менялись) в течении пары месяцев всё превратилось в такую кашу, что было принято решение полного рефакторинга... Так что в очень динамическом мире даже реляционная модель разваливается.

MN>>А именно к такой модели от модели реального мира в идеале ты и должен придти... Ещё раз подчеркну — в идеале.
B>Если Вы рисуете ОО модель товарно-денежных отношений между завскладом, товароведом, менеджером, бужгалтером, посавщиами и т.д. — это уже совсем-совсем другой коленкор.

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

B>>>Куда приткнуть логическое программирование, я, за недостатком образовния , просто ума не приложу.
MN>>Для реализации искусственного интеллекта .
B>Куда там! Мне бы со своим естественным разобраться.

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

MN>>Отвечу не своей мыслью, а мыслью авторитета. Применять надо тот подход который лучше знаешь и который проще применить для конкретной задачи. Допускается даже смешивание парадигм.
B>Вот вот. Поэтому интересн обыло бы знать где какая парадигма лучше работает.

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

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

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

B>Верно. Я сам на Питоне пишу. Однако идея динамического добавления методов пока в голову мою плохо укладывается.

Пример.
Миксин-классы в C++-подобных языках удобнее всего реализовывать с помощью шаблонов. В C#-пе шаблоны отсутсвуют, но .NET предоставляет функционал по генеарции классов и добавлению к ним методов прямо во время исполнения программы (Reflection) иногда эти возможности задействуют в шарпе для автоматической генерации миксин-классов в процессе исполнения.

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

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

B>1) Адекватно связать ОО структуру с реляционной базой — задача пока не решенная (да и вряд-ли будет когда-либо решена). Удобное отображение реляционных данных на ОО и наоборот вообще может оказаться задачей неразрешимой. Те, кто пользовался когда-либо слоями OR-маппинга знают, о чем идет речь. Все это происходит от того, что ОО модель и реляционная модель очень-очень разные вещи, построенные, между прочим, на разных принципах. Реляционная модель — данные, описываемые сущностями и отношениями, ОО медоль — данные и поведение, описываемые объектами. В частности, такая вот закавыка... В реляционной модели "все наружу", т.е. вся структура данных кишками смотрит на нас (ухмыляется ). В ОО модели отношения между объектами скрыты инкапсуляцией.
B>2) ИМХО ООБД и РСУБД никогда не будут совместимы, это миф. Все потуги добиться чего-то среднего (Обхектно-реляционные БД) привели лишь к большому кол-ву сложностей и, по сути, ни к чему хорошему. Я сторонник тов. Кодда и третьего манифеста.

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

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

B>Вы хотели сказать, объектной сущностью.

Отнюдь. Если выкинуть иерархические фишки, то отличие между XPath и SQL минимально.

B> Но это ничего не доказывает. Да, существуют языки запросов для ООБД. OQL например. И они совершенно нереляционные, а, скорее, обладают навигационными свойствами. Вспомните, в том же XPATH вы указываете путь до переменной (по сути навигация).

Нет. Навигация предполагает наличие курсора, а его в XPath нет. Путь в нем по сути аналогичен имени таблицы в SQL.

B> Само название XPATH уже о многом говорит.

О чем?

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

B>Мне всегда было не ясно, что же такое это интеллектуальное кэширование и чем оно лучше, чем кэширование записей (читай, сущностей) в РСУДБ ?

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

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

AVK>Еще раз — ты путаешь реляционные СУБД в их современном виде и реляционную структуру как принцип. Современные РСУБД в качестве аргумента реляции используют наиболее примитивную структуру из возможных — плоский список. Отсюда и проблемы с хранением объектов. Уже в XML с этим проблем на порядок меньше.
Не совсем понимаю. Дайте ссылку куда-нить, а то не пойму ничего никак.

AVK>Отнюдь. Если выкинуть иерархические фишки, то отличие между XPath и SQL минимально.
Нда. Вот только иерархическую сущность выкинуть непросто.

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

B>> Само название XPATH уже о многом говорит.

AVK>О чем?
О ПУТИ по которому нужно добираться до объекта.

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

B> Все хорошо, однако вот дальше разработки ООБД дело не пошло. Вся проблема заключалась в том, что я не смог получить удовлетворяющую меня модель предметной области с использованием ООБД.


По поводу классов

ООП заставляет программиста думать о предметной области в терминах объектов, но не классов объектов! Зачем Вам классы? Зачем Вам наследование классов? Если классификация оказывается полезной — хорошо, если классы бесполезны — тоже ничего страшного! ООП и Классы вовсе не близнецы-братья. Первичными являются именно объекты. Классы — лишь один из способов создавать объекты ни чуть не лучший других. Вот, например, другой способ: Программист садится за компьютер чтобы спроектировать новый объект. Он запускает специальный мастер и создает пустой объект. Этот объект персистентный. Программист может выключить компьютер, а объект сохраниться на диске. Придя на работу на следующий день, программист продолжит выращивание объекта дальше. На протяжении всего этапа проектирования/разработки объект будет живой. Объект живет в специальной среде. Когда компьютер выключается, объект сохраняется. После включения компьютера, объект продолжает жить дальше. Когда программист вырастит объект (добавляя к нему свойсва, методы и т.д.) до нужных ему "размеров", тогда программист сможет этот объект, например, продавать другим программистам. Но никакого исходного кода этого объекта не существует! Есть просто сам живой объект. Размножается он с помощью клонирования. Свой бинарный код он помнит сам. Если он попал (через сеть) на другой компьютер с другой архитектурой, то свой бинарный код он автоматически адаптирует в подходящий (например в 64 разрядный). Нету никаких классов, так как просто нету исходников, вообще нету!


По поводу ООБД

ОО программа в действии — это конгломерат объектов.Вот у нас есть конгломерат объектов взаимно ссылающихся друг на друга. Они находятся в оперативной памяти. Если компьютер выключить, то вся информация пропадет. Таким образом надо чтобы все объекты были персистентными и нужен механизм восстанавливающий все взаимные ссылки между объектами после загрузки этого конгломерата объектов обратно в оперативную память машины. Все это реализовывается элементарно. Например, у меня на Delphi это заняло всего около 2 тысяч строчек кода (в принципе, можно и меньше). То есть никакая ООБД вовсе не нужна до тех пор пока все объекты убираются в оперативной памяти. Проблема приходит когда количество объектов таково, что оперативной памяти компьютера не достаточно для их содержания. Объекты вместе с их взаимными ссылками надо хранить на диске/в сети на сервере/в интернете и ли еще где... В оперативной памяти все они уже не уберуться. Вот тут нужен механизм называемый ООБД. Но что конкретно нужно? Корень проблемы кроется в конечности размеров оперативной памяти, а нам хочется иметь, потенциально, бесконечную память. Так ведь? У нас есть модель бесконечной памяти. Мы создаем гигантские конгломераты (персистентных) объектов произвольным образом ссылающихся друг на друга. И хотим работать с этими титанами так как будто они все расположены в оперативной памяти нашего компьютера. Механизм, который создаст для нас работающую абстракцию модели бесконечной памяти — вот единственная цель ООБД. Что нам еще от нее требовать? Все остальное у нас и так есть! В идеале ООБД должна быть интегрирована с языком программирования и с операционной системой. Так что бы программист просто самым обычным способом писал самую обычную программу, вот только работающую с неограниченно большими количествами взаимосвязанных объектов, и при этом совершенно не задумывался бы о том что реально количество оперативной памяти очень ограничено. Там где-то стоят стойки из жестких дисков на которых реально записаны (персистентные) объекты, а может они доставляются через сеть, но программисту предоставлена абстракция бесконечной памяти, вот он с ней и работает точно также как в настоящее время работает с небольшими количествами персистентных объектов целиком убирающихся в оперативной памяти.

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

AVK>>Еще раз — ты путаешь реляционные СУБД в их современном виде и реляционную структуру как принцип. Современные РСУБД в качестве аргумента реляции используют наиболее примитивную структуру из возможных — плоский список. Отсюда и проблемы с хранением объектов. Уже в XML с этим проблем на порядок меньше.
B>Не совсем понимаю. Дайте ссылку куда-нить, а то не пойму ничего никак.

Какую ссылку? На то что объектные графы плохо ложаться на плоские таблицы? Или о чем ты?

AVK>>Отнюдь. Если выкинуть иерархические фишки, то отличие между XPath и SQL минимально.
B>Нда. Вот только иерархическую сущность выкинуть непросто.

Это уже неважно. Главное — XPath по сути тот же SQL для иерархических данных.

AVK>>Нет. Навигация предполагает наличие курсора, а его в XPath нет. Путь в нем по сути аналогичен имени таблицы в SQL.
B>Пожалйста, ссылку на источник такого определения, если можно.

Это не определение.

B>>> Само название XPATH уже о многом говорит.

AVK>>О чем?
B>О ПУТИ по которому нужно добираться до объекта.

Неа. По путям XPath нельзя добраться до объекта! Это лишь указание где искать. Более того — в XPath не существует типа данных, представляющего единичный объект. Единственный непримитивный тип это node set, набор(!) узлов. Но даже node set получается не только по пути, но и по условию. К примеру такой запрос SQL:

select a1 from some_place where a2=3

Будет иметь отдаленным аналогом такой запрос XPath

some_place[@a2=3]/@a1

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

Здравствуйте, Сергей Губанов, Вы писали:

почитай, например, реляционную алгебру и ты начнешь понимать, что же людям может быть нужно от OOБД...

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

_MM_>Здравствуйте, Сергей Губанов, Вы писали:

_MM_>почитай, например, реляционную алгебру и ты начнешь понимать, что же людям может быть нужно от OOБД...

Реляционная алгебра мне известна.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Реляционная алгебра мне известна.
В таком случае тебе, пожалуй, должна быть понятна мотивация изобретателей ODMG OQL. Почему-то их совершенно не удовлетворила сама по себе поддержка бесконечной памяти.

Здравствуйте, Borisman2, большое спасибо за поднятую тему и ссылки.
Но вот читал эту дискуссию и подумал: границы применимости в наших мозгах.
Типа, если у тебя есть молоток, то все в мире превращается в гвозди.
Я считаю, что ООП и конкретно С++ очень неплохой способ грамотно выражать свои мысли.
Но вот только этой грамотности нелегко научиться.
И цена использования какой-нибудь теоретически не новой двойной диспетчеризации
в конкретном проекте может быть весьма велика — я говорю о затратах на изучение
Loki или Boost, или повторное изобретение и отладку отечественных самокатов.
Научить всех членов команды использовать STL — и то неплохо будет.

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

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

B>>Мне всегда было не ясно, что же такое это интеллектуальное кэширование и чем оно лучше, чем кэширование записей (читай, сущностей) в РСУДБ ?

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

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

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

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

Не забывай про контекст — оптимизации кеширования, а не оптимизации вобще.

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

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

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

AVK>Не забывай про контекст — оптимизации кеширования, а не оптимизации вобще.
К большому сожалению, именно о ней и говорится.
1. Если обращение происходит только к внутренним данным объекта, то все нормально, и все как в РСУБД c их кортежами и экстентами.
2. Для сторед процедур можно построить и сохранить планы выполнения. Если запрошена проперть у ООСУБД, нельзя точно спрогнозировать что она для себя потребует в процессе выполнения. Внутренняя логика метода, со всеми if'ами и switch'ами, наследованием, перекрестными вызовами, может быть достаточно сложна для этого. Для этого отслеживают статистику, что было запрошено при выполнении этой проперти в прошлые разы. Но вполне понятно, что при редком попадании в какой-то if, вся эта стстистика летит насмарку.
Потому и называется интелектуальной, потому что реализовать простыми способами невозможно. Одна из фич, за которую критикуют ООСУБД.
С уважением, Gleb.

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

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

B>Вступление.
B>Совственно, к сабжу меня непосредственно привели 2 вещи
B>1) http://www.geocities.com/tablizer/oopbad.htm
B> пусть я не совсем согласен с автором касательно того, что ООП "в целом плохо", однако, как и у любой парадигмы (технологии, методологии, науки и вообще) у ООП, очевидно, есть границы применимости. Рекомендую сначала прочитать статью в приведенной ссылке.
Аналогично, не совсем согласен с автором, особенно с Table-Oriented Programming. Еще одна грыжа, не более того.

B>2) Мой собственный печальный опыт. Недавно (2 мес назад) я закончил разработку собственной ООБД (на самом деле это очень простая штука, не пугайтесь), по прототипу www.prevayler.org Предполагалось применение этой ООБД в реальном проекте по учету кредитования.
Посмотрел www.prevayler.org, сильно не дотягивает до нормальной OOCУБД.
B> Все хорошо, однако вот дальше разработки ООБД дело не пошло. Вся проблема заключалась в том, что я не смог получить удовлетворяющую меня модель предметной области с использованием ООБД. Сказались два фактора:
B> 1) "Многоклассовость" реального мира, реальный мир неукладывается в рамки определенной строгой классификации (попытки обойти это подробно описаны здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=833080&only=1

Автор: borisman2
Дата: 01.10.04

)
Тяжело описать просто то, что в реальном мире сложно устроено. Не надо, это перекладывать на недостатки метода. В реальном мире, пока человек не поймет как вещь устроена, он считает ее простой, и относится к ней как к некоторой абстракции. Хотя в некоторых случаях, недостатков у методики вагон, но и всегда есть нормальный выход из проблемы.
B> 2) Навигационная сущность ООП. Для того, чтобы получить доступ к какому-то обхекту, необходимо сначала найти корневой объект и затем пройти по цепочке других объектов до нужного объекта. Вчера я с ужасом понял, что именно по такому пути шли навигационные базы данных, умершие с появлением РСУБД!!! Другие методы — например, назначение каждому обхетку OID или хуже того, применение экстентов — это ведь строго говоря, кусочки реляционного подхода, применненые к ООБД
Наличие у обхетка OID, самое ценное что есть в ООСУБД. Это и есть нормальная идентификация объекта в отличие от реляционного подхода. Вообще, насколько я понял, ваше пессимистическое отношение в основном базируется на prevayler. Повторю, сильно недотягивает до нормального ООСУБД. Для того чтобы построить ООБД, нужно в него вложится не меньше чем в Oracle. И даже больше, поскольку внутренняя структура значительно сложнее. В основном ООСУБД, к сожалению, развиваются только на бумаге. Нормальных реализаций, даже в стандарте ODMG я не видел до сих пор. А стандарт вышел и умер до фигищи времени назад. Я не очень верю, что полноценная база данных может быть написана небольшой группой энтузиастов за короткое время.

B>Основная часть.
B>Всвязи с тем, что ООП явно не является лучшей (читай, универсальной) парадигмой, а также, похоже, не являются универсальными ни функциональное, нилогическое ни прочее другое программирование, я попытался хотя бы примерно обрисовать для себя границы применения этих парадигм. Т.е. ответить на вопрос: когда следует использовать фунцкиональный подход, когда ООП, когда процедурный и т.д. Оказалось не так-то просто ответить на этот вопрос.
B>Пока что мысли такие.

B>Для моделирования действительности лучше применять реляционный подход. К сожалению, предметная область (читай, реальный мир) как правило настолько сложна, что описать ДАННЫЕ (читай, атрибуты сущностей и отношения между ними) — уже дело не из легких. Если же сюда подключить еще и поведение (читай ООП), все настолько усложнится, что впору бросать проект.

1. Для моделирования действительности, лучше применять методы и инструменты, которые имеешь, знаешь и умеешь пользоваться. Для всего этого, и существует методы проектирования, начиная от Use-case'ов до дизайна программы. Что касается проблемы персистентности объектов, то это всего лишь небольшая часть всего этого процесса.
2. Сравнение РСУБД и ООСУБД, во многих сообщениях данного топика некорректно. ООСУБД содержит не только состояние объектов, но и его поведение. Соответсвенно, когда мы изменяем некоторое поведение, почему то обсуждается, насколько это легко сделать в реляционной структуре, но никак не затрагивается вопрос, что выше находится бизнес-логика объекта, которая тоже будет изменена. Соответсвенно, внесение изменений в реляционную+бизнес-объекты и ООСУБД, в принципе равнозначны.

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

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

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

Mr. None -> Re[6]: Границы применимости парадигм программирования

MN> А если кроме шуток, то упомянутый мной язык Self предоставляет как
MN> раз такие возможности:
MN> — динамическая смена предков объекта в процессе исполнения;
MN> — динамическое формирование списка методов и атрибутов объекта (там
MN> это называется одним словом "слот").

Хм... это и perl может

<!-- Yury Kopyl aka hrg | Гордость мешает доходам! -->

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

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

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

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

AVK>Неа. По путям XPath нельзя добраться до объекта! Это лишь указание где искать. Более того — в XPath не существует типа данных, представляющего единичный объект. Единственный непримитивный тип это node set, набор(!) узлов. Но даже node set получается не только по пути, но и по условию. К примеру такой запрос SQL:
AVK>

AVK>select a1 from some_place where a2=3
AVK>

AVK>Будет иметь отдаленным аналогом такой запрос XPath
AVK>

AVK>some_place[@a2=3]/@a1
AVK>

AVK>Синтаксис другой, суть та же. Понятно что таких аналогий для более сложных конструкций найти не так просто, но речь не об этом, а о том что подход, выражающийся в работе с наборами данных и их взаимодействиями применим и над иерархическими структурами. И проблема с объектами не в принципах, а в том что плоские структуры таблиц для этого плохо подходят. Уже переход на иерархические структуры заметно все упрощает, хотя в идеале конечно СУБД должна управлять графами. Увы, современное состояние IT пока не предлагает эффективных БД сетевой структуры.
Мне всегда казалось что проблема с сетевыми БД вовсе не в их эффективности. Если угодно, я могу написать на Питоне (на java чуть дольше, на C# тоже) сетевую БД, причем довольно быстро, и работать она будет весьма эффективно. Могу изложить основной принцип работы, если угодно. Впрочем, не претендую на профессионализм в данном вопросе, скорее всего у меня несколько дилетантский подход.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>По поводу классов

СГ>ООП заставляет программиста думать о предметной области в терминах объектов, но не классов объектов! Зачем Вам классы? Зачем Вам наследование классов? Если классификация оказывается полезной — хорошо, если классы бесполезны — тоже ничего страшного!
Все это верно, возможно я подумаю об использованиии прототипов в качестве способа создания классов и все уляжется.
СГ>По поводу ООБД

СГ>ОО программа в действии — это конгломерат объектов.Вот у нас есть конгломерат объектов взаимно ссылающихся друг на друга. Они находятся в оперативной памяти. Если компьютер выключить, то вся информация пропадет. Таким образом надо чтобы все объекты были персистентными и нужен механизм восстанавливающий все взаимные ссылки между объектами после загрузки этого конгломерата объектов обратно в оперативную память машины. Все это реализовывается элементарно. Например, у меня на Delphi это заняло всего около 2 тысяч строчек кода (в принципе, можно и меньше). То есть никакая ООБД вовсе не нужна до тех пор пока все объекты убираются в оперативной памяти. Проблема приходит когда количество объектов таково, что оперативной памяти компьютера не достаточно для их содержания.
Да, по очень похожей схеме работает моя самодельная-наколенке-писанная-ООБД. (Честно говоря, мне немного страшно ее так называть, уж чересчур она простая). Проблема нехватки памяти (по крайней мере, на моих задачах) пока не стоит и не предвидится. На самом деле кроме того, чтобы сохранять обхекты еще есть пара заморочек — например, транзакции. Даже с локальной работой без них — никуда.


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

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

GZ>1. Если обращение происходит только к внутренним данным объекта, то все нормально, и все как в РСУБД c их кортежами и экстентами.
Верно
GZ>2. Для сторед процедур можно построить и сохранить планы выполнения.
Верно, с оговорками. А как же if? а циклы?
GZ>Если запрошена проперть у ООСУБД, нельзя точно спрогнозировать что она для себя потребует в процессе выполнения.
Почему это невозможно?
GZ>Внутренняя логика метода, со всеми if'ами и switch'ами, наследованием, перекрестными вызовами, может быть достаточно сложна для этого.
Хм. На первый взгляд, ничего сверхъестественного.
GZ> Для этого отслеживают статистику, что было запрошено при выполнении этой проперти в прошлые разы.
А это кто например? Можно ссылку на ООСУБД, которая это умеет?
GZ>Но вполне понятно, что при редком попадании в какой-то if, вся эта стстистика летит насмарку.
GZ>Потому и называется интелектуальной, потому что реализовать простыми способами невозможно. Одна из фич, за которую критикуют ООСУБД.
Ну, зато у нас есть сложные способы. Я вот сейчас упражняюсь в построении одного из них. Возможно, я и упрусь в какой-то непреодолимый предел.
Уже сейчас очевидно, что далеко не во всех случаях можно будет получить 100% оптимальный план запроса. Основные заметные препятствия — рекурсия/циклы и исключения.
То есть вряд ли удастся привести предикат вида

Factorial(self.Salary)<120

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

self._salary < 5

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

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