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

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

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

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

Может в будущем мы будем видеть в программах вместо class Control{ Control Parent; Control[] Children;}

что нибудь вроде table Control{Control Parent; index Children{Control.Parent = this}} ?

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

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

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

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

Очень бы хотелось.
У меня в проекте все данные хранятся в списках. Я очень часто вынужден их сортировать, перебирать во вложенных циклах для поиска и т.д.

Очень хочется просто написать

Select * from list2
where obj_Id in (Select id from list)
order by parentId

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

BE>Очень хочется просто написать

BE>Select * from list2
BE>where obj_Id in (Select id from list)
BE>order by parentId
пишите не C# используя linq там это почти так и выглядит.

ужас ужас.

завел я значит временную переменную для своих секретных нужд.
а кто то в совершенно посторонней части программы получил ее значение.

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

C>ужас ужас.

C>завел я значит временную переменную для своих секретных нужд.
C>а кто то в совершенно посторонней части программы получил ее значение.

Ну, люди уже десятилетия назад над этим голову ломали.
Придумали ACID (Atomicity, Consistency, Isolation, Durability)
Думаю, концепции Atomicity и Isolation помогут решить сложности с локальной переменной.
То есть пока транзакция не завершилась, никто кроме вас, ваш обьект не увидит.
А когда завершилась — пусть смотрят.

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

C>>ужас ужас.
C>>завел я значит временную переменную для своих секретных нужд.
C>>а кто то в совершенно посторонней части программы получил ее значение.
C>Ну, люди уже десятилетия назад над этим голову ломали.
C>Придумали ACID (Atomicity, Consistency, Isolation, Durability)
C>Думаю, концепции Atomicity и Isolation помогут решить сложности с локальной переменной.
C>То есть пока транзакция не завершилась, никто кроме вас, ваш обьект не увидит.
C>А когда завершилась — пусть смотрят.
ну во первых придется на пустом месте городить управление транзакциями на ровном месте.

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

C>ну во первых придется на пустом месте городить управление транзакциями на ровном месте.
Если вдуматься, описанный вами сценарий — не совсем ровное место.
Ведь фраза "а кто то в совершенно посторонней части программы получил ее значение" подразумевает многопоточное(асинхронное) программирование,
а при таком раскладе управление транзакциями — то, что доктор прописал.

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

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

Для этого давным давно придумали паттерн DI — Dependency Injection.

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

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

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

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

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

Я пытаюсь обсудить следующую тему. Если в рантайме и синтаксисе языка программирования появятся средства, традиционные для субд, такие, как возможность выборки по обьектам определенного типа, транзакции, ACI(D?) — не станет ли программирование удобнее, программы выразительнее, архитектура прозрачнее.
Сложности, которую вы описываете, при программировании в субд не встречается, никто не видит обьект, из другой транзакции, а если видит, то так задумано. В необходимости понятия транзакция тоже никто не сомневается. Просто дана такая модель и ее примитивы, их, конечно следует знать, что бы работать в рамках данной модели.
Но если взять на себя труд освоить эти примитивы, может быть разработка упростится?
В этом мой вопрос.
Конечно, создать такой рантайм это труд, может быть даже не реализуемый эффективно в настоящее время, но это хочется оставить за рамками обсуждения.

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

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

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

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

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

Какой смысл Вы можете закладывать, собирая в одну коллекцию ВСЕ экземпляры какого-то класса? (я не к том, что таких желаний не возникает, но это хоть какой-то смысл это имеет оочень редко)

Или я чего не понимаю?

Здравствуйте, Stanislav V. Zudin, Вы писали:

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

Я и подразумеваю, что делать нужно, как в РСУБД.
То есть в таблицах хранить кортежи.

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

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

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

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

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

Y>Это не заставляет, а даёт возможность хранить указатели на связанные объекты.
Y>Вед это же рантайму эти указатели нужны просто для того, что бы объекты объекты не отправились в "космос" и до них можно было дотянуться.
Y>А для Вас эти указатели -- отражения ваших замыслов (концептуальных связей между объектами).
Y>Если по Вашей задумке сколько-то объектов одного типа должны лежать в одной коллекции, ну так и положите их в одну коллекцию.

Y>Какой смысл Вы можете закладывать, собирая в одну коллекцию ВСЕ экземпляры какого-то класса? (я не к том, что таких желаний не возникает, но это хоть какой-то смысл это имеет оочень редко)

Y>Или я чего не понимаю?

Тут такая вещь. Связи между обьектами (или коллекции), пожно разделить на два типа.
Один тип — связь жесткая, установленная by defenition, раз и навсегда.
Например, пользователь выбрал из списка ЭТОТ элемент.
Гораздо чаще связи или коллекции определяются логически, при помощи некоторого предиката.
Например, коллекция дочерних элементов, ссылка на рабочую транзакцию и т п.
Тут проблемы.
Состав таких коллекций или ссылок вообще говоря меняется по мере изменения данных программы.
То есть его нужно либо вычислить по требованию в нужный момент, либо постоянно отслеживать изменения связанных данных и менять состав коллекций. Второй путь традиционный для рантаймов, первый — для субд. Мне первый путь кажется многообещающим. Но применить его можно, только имея индексированный список всех подходящих обьектов, которые могут быть выбраны предикатом.

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

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

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

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

C>Здравствуйте, Stanislav V. Zudin, Вы писали:

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

C>Я и подразумеваю, что делать нужно, как в РСУБД.
C>То есть в таблицах хранить кортежи.

А в чем проблема? Берем C#3 и выше, "реляции" — IEnumerable<T>, таблицы — коллекции вроде List, HashSet итп, "кортежи" — классы (только в БД у них структурая типизация, а в C# — номинативная), для запросов Linq. Сверху накручвай индексацию как удобно и пользуй.

Для атомарности действий есть stm, но stm.net недавно с devlabs убрали. В принципе иммутабельность даже выгоднее получается, чем управление блокировками.

On 31.05.2011 13:58, Chrome wrote:

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

Храни, кто тебе запрещает ?

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

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

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

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

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

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

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

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

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

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

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

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

Сделать нормальный linq провайдер достаточно сложно, но ты попробуй. Посоветуйся с IT, он с ним пуд соли съел.