ИМХО, чел выучил скуль и научился ваять странички, а готовить нормальные ЯП так и не научился -- непривычно, а потому и неудобно )))
И его осенила "гениальная" идея -- сделать везде так, как в СУБД. В общем, трезвые мысли на этот счет уже и так высказали выше...

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

C>>Например, коллекция дочерних элементов,

Y>Чем большая таблица дочерних элементов с внешними ключами на родителей лучше многих маленьких коллекций, "принадлежащих" родителям?

Тем, что когда вы захотите получить детей некоторого родителя, в реляционном подходе вы именно их и получите — все элементы, удовлетворяющие предикату "parent-child".
Если же у вас множество коллекций у разных родителей, вы, вообще говоря, получите то, что в эти коллекции когда-то кем то было положено. ВЫ должны гарантировать, что не забыли положить то что надо, не забыли убрать, что не надо. В тривиальном случае parent-child и то нужно отслеживать множество потенциальных изменений. В более сложных отношениях поддержание коллекций в актуальном состоянии — головная боль. Может при появлении детей еще не быть обьекта родителя, а когда появится обьект родитель, не будет удобного доступа к обьектам детей.(в нетривиальных предикатах такое нередко)
В общем дети-родители это был самый банальный пример, не стоит на нем зацикливаться.

Y>Я понимаю, что велик соблазн получить одним селектом все позиции всех заказов минуя сами заказы, но Вы не находите это некоторым читерством?

человеческие мозги легко допускают такую логическую конструкцию, не вижу причин их ограничивать.

Y>Вы же понимаете, что экземпляры этого класса (а Вы предложили поместить их в одно "энумерабельное" множество) могут не только принадлежать заказам, но так же, например, лежать в текущих "ненаказанных корзинах".

Думается, мощность реляционного исчисления эквивалентна или больше исчислению на графах обьектов. так что все решаемо.

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

MZ>Как бы таблицы реляционные неполиморфны, объекты -- наоборот,
MZ>полиморфны, если в иерархиях, если делать это так, как делают
MZ>в РБД, выглядело это бы совсем по-идиотски.

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

>> В типичном рантайме есть графы обьектов разных типов. И можно только
>> перемещаться по связям в этих графах, что бы добраться до нужного обьекта.
>> Это ограничение заставляет хранить в сущностях указатели на связанные обьекты,
>> что пораждает всякие архитектурные извращения и проблемы.
>> Проблемы в том, что эти связи нужно вовремя инициализировать,
>> Некоторые связи актуальны не все время жизни обьекта,
>> Что бы перейти от одного обьекта к другому, алгоритм должен обладать знанием
>> структуры графа обьектов.
>> В реляционной модели без этого можно обойтись.

MZ>Безусловно. Но именно потому, что в программах эти связи есть
MZ>в явном виде, программы и работают быстро всегда, в отличие от запросов
MZ>SQL, которые ОЧЕНЬ гибкие, но ОЧЕНЬ непредсказуемы по производительности.

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

MZ>Кроме этого, ООП и РБД на самом деле страшные антогонисты.
MZ>РБД (да и любая БД) невозможно представить без того, что
MZ>в ООП называется нарушением инкапсуляции.

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

Хотя на мой вкус, инкапсуляция — всего лишь средство поддержания инвариантов в обьекной модели.
Если ввести транзакции и проверять инварианты при комите, может ну ее нафиг, эту инкапсуляцию?

>> Просто пишем linq query и получаем нужные данные.
>> Эффективность повышаем за счет индексов.

MZ>Угу, сказочки...
MZ>Построй-ка мне индексы для возможности пользователю делать произвольную
MZ>сортировку по любому набору любых атрибутов объектов класса.

в чем вообще сложность? очевидное решение — набор индексов для всех возможных порядков атрибутов. Обьекная модель не предлагает никаких преимуществ.

On 01.06.2011 0:10, Chrome wrote:

> В рантайме все обьекты — это типичные кортежи, только хаотически разбросанные по
> куче.

Кортежи-то кортежи, да с переменным числом атрибутов (изза наследования).

Я всего лишь предлагаю сгруппировать кортежи, имеющие одинаковый тип в
> таблицы.

А разный тип ? В разные таблицы ?
Ну и что ж у тебя будет в итоге ? Столько таблиц, сколько типов ?
А если тебе надо коллекцию ПОЛИМОРФНЫХ объектов хранить и обрабатывать,
как её будешь хранить ? А в этом, знаешь ли, вся суть ООП.

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

Ну, думай далее.

> Кроме того появляются некоторые дополнительные интересные возможности —
> выполнять запросы и создавать обновляемые индексы.



> Мне кажется, каждая связь в обьектной может взаимно однозначно моделироваться
> соответствующим индексом в реляционной модели,

Не совсем тоже однозначно всё. В ООП все связи однонаправленные.
Нет связей "многие ко многим". В реляционной модели все связи двунаправленные,
и есть "многие ко многим".

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

Нет. Выборка по индексу -- это что-то типа O( ln N ). Переход в ООП по связи --
O( 1 )

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

Это как ? Там собственно всё просто, как индексы строить будешь ?
Где данные для них возмёшь ?
На самом деле все ORM-ы видимо так и делают -- мягко и ненавязчиво нарушают
инкапсуляцию, делая это нежно и бережно, но проблема-то от этого на самом
деле никуда не девается.

> Хотя на мой вкус, инкапсуляция — всего лишь средство поддержания инвариантов в
> обьекной модели.
> Если ввести транзакции и проверять инварианты при комите, может ну ее нафиг, эту
> инкапсуляцию?

Ну как бы в объектных СУБД так и поступают, да только ООП без инкапсуляции --
это всё равно что секс без женщины.

> в чем вообще сложность? очевидное решение — набор индексов для всех возможных
> порядков атрибутов.

Вот в этом и сложность
Сколько наборов атрибутов-то посчитал уже ?

On 31.05.2011 15:31, Chrome wrote:
> Ну, люди уже десятилетия назад над этим голову ломали.
> Придумали ACID (Atomicity, Consistency, Isolation, Durability)

Там ещё одной буковки нет, Incapsulation.

> Думаю, концепции Atomicity и Isolation помогут решить сложности с локальной
> переменной.
> То есть пока транзакция не завершилась, никто кроме вас, ваш обьект не увидит.
> А когда завершилась — пусть смотрят.

А если некуда смотреть ? Нет если этих данных вообще, не существуют,
выдаются по требованию, вычисляясь на ходу ?

Здравствуйте, Chrome, Вы писали:
C>Я пытаюсь обсудить следующую тему. Если в рантайме и синтаксисе языка программирования появятся средства, традиционные для субд, такие, как возможность выборки по обьектам определенного типа, транзакции, ACI(D?) — не станет ли программирование удобнее, программы выразительнее, архитектура прозрачнее.
Станет — см. linq.

C>Сложности, которую вы описываете, при программировании в субд не встречается, никто не видит обьект, из другой транзакции, а если видит, то так задумано. В необходимости понятия транзакция тоже никто не сомневается. Просто дана такая модель и ее примитивы, их, конечно следует знать, что бы работать в рамках данной модели.
Эта сложность не встречается в СУБД ровно потому, что в них никто ничего не программирует. СУБД используется только как репозиторий — там лежат данные, и чуть-чуть логики. Всё интересное происходит в прикладной программе на традиционном ЯП, где не нужно бояться за невидимость переменной на стеке.

C>Конечно, создать такой рантайм это труд, может быть даже не реализуемый эффективно в настоящее время, но это хочется оставить за рамками обсуждения.

Нужно просто понять, что именно понимается под таким рантаймом. Вы уже посмотрели на linq? Посмотрели на GemStone?

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

MZ>Безусловно. Но именно потому, что в программах эти связи есть
MZ>в явном виде, программы и работают быстро всегда, в отличие от запросов
MZ>SQL, которые ОЧЕНЬ гибкие, но ОЧЕНЬ непредсказуемы по производительности.

MZ>Кроме этого, ООП и РБД на самом деле страшные антогонисты.
MZ>РБД (да и любая БД) невозможно представить без того, что
MZ>в ООП называется нарушением инкапсуляции.
Отчего же? Не вижу никаких причин невозможности такое представить. Вот пишете вы, допустим, запрос:

from d in documents select d where d.IsReady();

d имеет тип IDocument. Получаем результат безо всякого нарушения инкапсуляции.
Нарушение инкапсуляции происходит "внутри" движка; там он может выполнить раскрытие реализаций IsReady, и построить план запроса с учётом имеющихся индексов.

MZ>Угу, сказочки...
MZ>Построй-ка мне индексы для возможности пользователю делать произвольную
MZ>сортировку по любому набору любых атрибутов объектов класса.
Задачи "построить набор индексов для оптимизации всех предикатов и всех ключей сортировки" в природе не встречается.
Если совсем уж припрёт, то, очевидно, хватит N! различных индексов, где N — количество атрибутов класса.

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

MZ>Отчасти — может. Но боюсь не в том виде, что ты себе представляеш.

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

C>Кроме того появляются некоторые дополнительные интересные возможности — выполнять запросы и создавать обновляемые индексы.
Обновляемость индексов никак не связана с группировкой в таблицы. Она связана с перехватом всех модифицирующих операций.
Поймите, что вопросы физического расположения данных в таблицах связаны исключительно с особенностями блочного доступа к диску. В памяти быстродействие устроено несколько по-другому; типично реляционные задачи обычно таковы, что вопросы неизотропности памяти для них вторичны.

C>Мне кажется, каждая связь в обьектной может взаимно однозначно моделироваться соответствующим индексом в реляционной модели, выборка по такому индексу эквивалентна по алгоритмической сложности переходу по связи в обьектной модели, так что никакой непредсказуемой разницы в производительности быть не должно.

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

C>Хотя на мой вкус, инкапсуляция — всего лишь средство поддержания инвариантов в обьекной модели.
C>Если ввести транзакции и проверять инварианты при комите, может ну ее нафиг, эту инкапсуляцию?
Инкапсуляция — средство борьбы со сложностью, а не поддержания инвариантов.

C>в чем вообще сложность? очевидное решение — набор индексов для всех возможных порядков атрибутов. Обьекная модель не предлагает никаких преимуществ.

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


Z>Предлагаешь сделать оптимизатор для linq query? В принципе идея интересная, но для данных которые в ОЗУ обычно нет более менее эффективного универсального алгоритма поиска/сортировки. А для тех данных, которые из за размера приходится сбрасывать на диск, внешние инструменты подходят лучше.
Был такой провайдер. Начинал ускорять с длины списков в ~16 и более элементов

Z>Сделать нормальный linq провайдер достаточно сложно, но ты попробуй. Посоветуйся с IT, он с ним пуд соли съел.
Поэтому надо взять готовый и PROFIT: http://i4o.codeplex.com/

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

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

C>В часности, хранить данные одного типа сгруппироваными в "таблицы".
C>Имеется в виду возможность итерации по всем обьектам одного типа в домене или выборки по индексу.
C>В типичном рантайме есть графы обьектов разных типов. И можно только перемещаться по связям в этих графах, что бы добраться до нужного обьекта.
C>Это ограничение заставляет хранить в сущностях указатели на связанные обьекты, что пораждает всякие архитектурные извращения и проблемы.
C>Проблемы в том, что эти связи нужно вовремя инициализировать,
C>Некоторые связи актуальны не все время жизни обьекта,
C>Что бы перейти от одного обьекта к другому, алгоритм должен обладать знанием структуры графа обьектов.
C>В реляционной модели без этого можно обойтись.
C>Просто пишем linq query и получаем нужные данные.
C>Эффективность повышаем за счет индексов.

C>Может ли такой подход пойти в мейнстрим — в методологию программирования?

ABAP internal tables (примерчик).

On 07.06.2011 19:36, Sinclair wrote:

> Отчего же? Не вижу никаких причин невозможности такое представить. Вот пишете
> вы, допустим, запрос:
>
> from din documents select d where d.IsReady();

Ох вы умный-то какой, а!
А что, нужно, чтобы метод IsReady() был бы determenistic,
как считаете ? А кто это гарантировать будет ?

> Задачи "построить набор индексов для оптимизации всех предикатов и всех ключей
> сортировки" в природе не встречается.

Считайте, что я её вам задал.
Мне такую задачу в реальности задавали.

> Если совсем уж припрёт, то, очевидно, хватит N! различных индексов, где N —
> количество атрибутов класса.

Ну, вам нравится такое ?

> А в реальных задачах — реальные запросы, их не так уж много. Прикрутить индексы

На самом деле многое из того, о чём вы тут говорите, есть в разных языках
программирования, например, в Common Lisp или Smalltalk. FoxPro кстати ..
Но вот именно в таком виде не хотел бы это видеть в языке даже я, в общем-то
большой фанат реляционных БД. По одной простой причине -- когда вы пишите на
языке программирования общего назначения, все данные у вас в памяти.
Это очень приятно и очень полезно, и O(N) там вовсе не страшно,
а страшнее там M!*F(N) памяти под индексы.

Да, напомню, если вы подзабыли, что операции с данными в памяти в тысячи (самая
скромная оценка) раз быстрее аналогичных с данными на диске.

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

MZ>Ох вы умный-то какой, а!
А то. Я эту тему плотно изучал, лет эдак 10 назад.
MZ>А что, нужно, чтобы метод IsReady() был бы determenistic,
MZ>как считаете ? А кто это гарантировать будет ?
Нет, не нужно. Можно и безо всякой детерминистичности обойтись. Просто это будет означать сваливание в full scan.
А если метод оказывается детерминистическим, да ещё и удачно замкнут по свойствам экземпляра, то можно и индексы подключить.

MZ>Считайте, что я её вам задал.
MZ>Мне такую задачу в реальности задавали.
Расскажите, как вы решаете её в РСУБД.

MZ>На самом деле многое из того, о чём вы тут говорите, есть в разных языках
MZ>программирования, например, в Common Lisp или Smalltalk. FoxPro кстати ..
MZ>Но вот именно в таком виде не хотел бы это видеть в языке даже я, в общем-то
MZ>большой фанат реляционных БД. По одной простой причине -- когда вы пишите на
MZ>языке программирования общего назначения, все данные у вас в памяти.
MZ>Это очень приятно и очень полезно, и O(N) там вовсе не страшно,
MZ>а страшнее там M!*F(N) памяти под индексы.
Вы ошибаетесь. На ЯОН тратится довольно много усилий на борьбу с O(N). Заметьте, насколько популярны всякие HashSet и Dictionary. Просто там все настолько привыкли к тому, что всё надо делать вручную, что желание просто написать from page in pageCache select page.Content where p.ExpDate > DateTime.Now && p.Url = url кажется противоестественным.

MZ>Да, напомню, если вы подзабыли, что операции с данными в памяти в тысячи (самая
MZ>скромная оценка) раз быстрее аналогичных с данными на диске.
Это всего лишь означает, что алгоритмы размещения данных, применяемые в СУБД, в памяти неактуальны.

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

S>Вы ошибаетесь. На ЯОН тратится довольно много усилий на борьбу с O(N). Заметьте, насколько популярны всякие HashSet и Dictionary. Просто там все настолько привыкли к тому, что всё надо делать вручную, что желание просто написать from page in pageCache select page.Content where p.ExpDate > DateTime.Now && p.Url = url кажется противоестественным.

Потому что объекты != данные. Доступ к данным с фиксированной разметкой дешевый, а к произвольному св-ву произвольного объекта — дорогой.

On 08.06.2011 5:40, Sinclair wrote:

> Нет, не нужно. Можно и безо всякой детерминистичности обойтись.
Уверены на 100% ?

> MZ>Считайте, что я её вам задал.
> MZ>Мне такую задачу в реальности задавали.
> Расскажите, как вы решаете её в РСУБД.

Никак. Я отказался от решения такой задачи.

> Вы ошибаетесь. На ЯОН тратится довольно много усилий на борьбу с O(N). Заметьте,
> насколько популярны всякие HashSet и Dictionary. Просто там все настолько
> привыкли к тому, что всё надо делать вручную, что желание просто написать from
> page in pageCache select page.Content where p.ExpDate > DateTime.Now && p.Url =
> url кажется противоестественным.

Я как бы не против, я как бы скорее на вашей стороне в споре, однако я не
столь радикален.

> MZ>Да, напомню, если вы подзабыли, что операции с данными в памяти в тысячи (самая
> MZ>скромная оценка) раз быстрее аналогичных с данными на диске.
> Это всего лишь означает, что алгоритмы /размещения/ данных, применяемые в СУБД,
> в памяти неактуальны.

Нет, это всего лиш означает, что там, где в СУБД невозможно представить алгоритм
с O(N), в ЯВУ такой алгоритм запросто может работать. И тут ничего страшного нет.

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

S>Инкапсуляция — средство борьбы со сложностью, а не поддержания инвариантов.
"а" здесь лишнее. Инкапсуляция — средство борьбы со сложностью поддержания инвариантов. Это я понял, перейдя с Джавы на С.

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

V>Потому что объекты != данные. Доступ к данным с фиксированной разметкой дешевый, а к произвольному св-ву произвольного объекта — дорогой.
Во-первых, фиксированность разметки данных в современных СУБД — всего лишь иллюзия. Времена dBase давно миновали, даже Access уже не вычисляет положение поля в файле как RecNo * RecSize + FieldOffset.
Так что скорость исполнения запросов зависит не от фиксированности разметки.
Во-вторых, речь вообще не идёт о доступе как таковом. Вся идея оптимизации запросов — в том, чтобы не делать лишних обращений к данным.

В-третьих, объекты одного класса на большинстве современных промышленных языков программирования имеют вполне себе фиксированную разметку.
Это означает, что запрос типа
from IEmployee e in AllEmployees select e where e.Tenure > TimeSpan.FromYears(1)
можно переписать как union из запросов типа
from RegularEmployee re in AllEmployees.As<RegularEmployee> select re where re._hireDate < DateTime.Now — TimeSpan.FromYears(1)
и
from ContractEmployee ce in AllEmployees.As<ContractEmployee> select ce where ce._contractDuration > TimeSpan.FromYears(1)

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

>> Нет, не нужно. Можно и безо всякой детерминистичности обойтись.
MZ>Уверены на 100% ?
Конечно.
>> Расскажите, как вы решаете её в РСУБД.
MZ>Никак. Я отказался от решения такой задачи.
Ну, так почему же вы требуете её решения от других?

MZ>Нет, это всего лиш означает, что там, где в СУБД невозможно представить алгоритм
MZ>с O(N), в ЯВУ такой алгоритм запросто может работать. И тут ничего страшного нет.
В целом — согласен. Но, опять же, изобилие всяких HashSet и прочих Dictionary как бы показывает, что проблема поиска быстрее O(N) в памяти таки существует.

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

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

Вам сюды: http://reocities.com/tablizer/prtips.htm

Иными словами: xBASE рулит. Вообще взгляд вполне валидный хотя бы с той точки зрения что в xBASE мы имели коллекции неограниченной мощности (вместо массивов, списков, слвоарей — таблицы). Только он немейнстримный и сгинуть там в непроглядной тьме — пара пустяков, оцените свои силы .

MZ>Нет. Выборка по индексу -- это что-то типа O( ln N ).
по факту нет. там логарифм по основанию от 10 до 100 с типичным значением ближе к 50. При таких степенях его можно смело считать константой