ViPRosserg99Мы пока не встречали задач которые нельзя было бы моделировать объектами. Даже тесты TPC. Сам процесс познания имеет "объектный" характер. Таблицы же это скорее удобный способ представления данных в процессе их обработки.
ну если все (контексты, типы, события, процессы, время, пространство,....) назвать объектами, то да
А что их лучше назвать табличками? :-)

ViPRosserg99,

процесс познания носит "процессный" характер
и "процесс" этот называется "классификация"
ООП не может "классифицировать"
А классификация чего? Наверное ведь не таблиц.

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

U-gene А Вы попробуйте представить себе компьютер у которого вся память персистентна (типа флеш). Персистентность данных - основное св-во которое реализует РСУБД. У меня РСУБд является машиной, а не средством хранения данных . Хотя с вашим "по диагонали".... о чем я говорю?

Можно даже представить что всё что есть - это энергонезависимое ОЗУ. Тем не менее все равно где то есть описание (двоичный код)программного объекта, который становится "живым" только после запуска соответствующей программы. Просто мне представляются эти немного философские расуждения о разнице между моделью вычислений и моделью данных важными независимо от того в какой степени это относится к Вашему подходу.


U-geneSerg99Если у Вас все наследники имеют одинаковый набор свойств, то непонятно зачем такая иерархия наследования.

Опана. :) А что же тут непонятного? Есть класс AА. В нем определено свойство аа. Есть класс-наследник ББ. У него есть св-во бб и, также, он унаследовал св-во аа. Исходя из того, что речь идет о наследовании, можно предполагать, что объекты класса ББ можно так же рассматривать так же как объекты класса АА, что подтверждается тем, что у него есть свойства аа (точно так же как у любых других объектов класса АА). А в обратную сторону это не работает. Объекты класса АА не являются объектами класса ББ - и у них нет тех свойств, которые есть в ББ.

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

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

По моему, это очевидно. Всегда так было.

Но судя по необходимости использовать значения, "обозначающее отсутствие свойств" - у Вас как то по другому. Такое.... лихое.... наследование. Или уже не наследование?

Я так и не понял какие множества объединяются Вашим UNION и в чем собственно фишка если всё делается как всегда.

Допустим у нас есть класс "Средства_передвижения" с наследниками "Автомобили" и "Лошади". Соответственно у автомобилей есть атрибут "Количество_колес", а у лошадей - "Количество_ног". Потом мы делаем запрос

На выходе получаем:


То есть в базе заданы два автомобиля и две лошади. NULL потому что количество колес для ГАЗ-24 забыли задать, а NotDef потому что у лошадей вообще нет такого атрибута. Собственно отсюда должно быть понятно что я говорил о случае, когда в одно множество объединяются объекты разных классов и что спецзначение NotDef относится к случаю выполнения операций над такими множествами.

Что касается "Наследования", то если отойти от устоявшейся ООП терминологии я бы лучше назвал это "Уточнение/Обобщение" в зависимости от того в какую сторону иерархии мы "смотрим". Действительно семантику "Наследования" можно доопределить, как впрочем возможны и другие взаимоотношения между Классами.

U-geneSerg99большинство задач можно решить используя только С# эта фраза и меня поразила. Например. что такое LINQ без MS SQL?

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


U-geneSerg99Долго объяснять :-) Ну.... это же так интересно! Какое же отношений количество ссылок имеет к их направлености? КМК никакого. Тут и объяснять нечего. Вы, в очередной раз прочитав по диагонали, решили блеснуть эрудицией... и в очередной раз не попали.

Как Вам угодно. Хочу только заметить что я не писал про связь количества ссылок с их направленностью. Моя реплика была связана с

1) с Вашим ответом одному из участников на вопрос "а если мне нужно наоборот" и относилась к тому что синтаксис запроса где нужно было "наоборот" мало отражал сильно изменившуюся семантику.

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


А если бы мне хотелось получить список возрастов учителей обучающих заданное множество учеников, то мне хотелось бы написать


Отсюда же видно что смысл "точки" в зависимости от контекста совершенно разный.

А скажем запрос типа


Выводил бы список имен учеников, которые являются детьми сотрудников Банков, клиентами которых являются их учителя.

2) Между объектами скажем одной и той же пары классов могут существовать разнотипные ссылки различающиеся своей семантикой (в том числе различные по 1:N, N:1 или N:N). Это добавляет многомерность во взаимосвязи между объектами.


U-geneSerg99"По хорошему" это когда точечной записью можно сформулировать полноценный SQL подобный запрос. Примеры потребуют углубления в модель данных Так давайте углубимся, прямо злесь.... если это, конечно, не просто очередное прочтение по диагонали.
См. выше. У меня нет много времени углубляться дальше.

U-geneSerg99Я так и не понял какие множества объединяются Вашим UNION и в чем собственно фишка если всё делается как всегда.

После диагонали - что можно понять?

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

Это не для среднего ума. :-)

U-geneSerg99 На выходе получаем:

Имя Количество_колес
ВАЗ21-07 4
ГАЗ-24 NULL
Вороной NotDef
Кляча NotDef

Это конечно оригинально, но по мне система банально должна вернуть ошибку.

А по мне так должна ответить всё что может по сути запроса.

Например, что у Вас будет, если кто-нибуть случайно попытается выполнить запрос
?[/quot]
Будет ошибка.

U-geneserg99

Давайте начнем со старого вопроса - что будет, если кто-то спросит случайно
?

Будет ошибка.


U-gene По делу. Если мы говорим о системе со строгим ранним контролем типов, то куда ссылка есть - туда и спрашивать можно. Это всега так было (именно поэтому ODMG требует явных встречных ссылок). Однако я могу использовать эту же ссылку и в обратную сторону.

Не пойму в чем здесь фишка. Если по прямой ссылке можно восстановить обратную, то нет разницы задана обратная ссылка вдобавок явно или нет. Здесь как правило выбирается баланс между быстродействием и избыточностью данных. А так же принципом "быстрее положишь - медленней возьмешь, и медленней положишь - быстрее возьмешь". Если избыточность (требуемая ODMG) позволяет ускорить работу, то и слава богу, особенно если автоматом обеспечить ссылочную целостность. Кстати ссылочная целостность - это одна из проблем реляционных БД, которую мы решили.

U-geneНапример, есть ссылка только из учителей в ученики.
Если я я хочу узнать имена учеников учителя Петрова. (логическая цепь - Учителя.Ученики.Имя), я спрошу

И по той же ссылке я могу узнать имена учителей ученика Иванов (логическая цепь - Ученики.Учителя.Имя), я спрошу

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

Хладный труп ODMG пытаются реанимировать, но пульс близок к нулю. :-)

Никто не мешает выполнить запросы

Учителя[имя="Петров].Ученики.Имя;

и

Ученики[имя="Иванов"].Учителя.Имя;

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

[quot U-gene]Я еще раз говорю, что речь идет о системе с ранним строгим контролем типов.
Так а в чем здесь проблема? Естественно система должна обеспечивать контроль типов на этапе компиляции/интерпретации запросов.

U-geneserg99Отсюда же видно что смысл "точки" в зависимости от контекста совершенно разный.
Ничего не видно. К акой контекст? какой разный смысл? Это просто обращение по ссылке - если он есть.

У нас это не просто обращение по ссылке.

U-geneКстати (забыл уточнить), все эти примеры - это как бы Вам хотелось? или как оно у Вас уже есть?
Я загрубляю то что есть. Но работы ещё очень много.

U-geneА почему она будет? Может же в этом случае система выводить для всех объектов NotDef?
Почему же для Количества_колес ошибки не будет, а для К а личества_ колес - будет. Ведь в средствах передвижения, к которым Вы обращаетесь, нет ни Количества_колес, ни К а личества_колес.

Хотя бы у одного наследника есть "Количество_колес".

U-geneОткуда пользователь узнает, что Количества_колес можно , а К а личества_колес нельзя. Он же работает с средства_передвижения. Там никаких количеств вообще нет. Откуда пользователь вообще про эти количества узнает?

Из "метаданных". Если он сам эти метаданные вводил, то может и просто вспомнить.

U-geneИ зачем надо было вообще определять отдельно средства_передвижения?

Это всё действительно не для среднего ума.

И это не типизация, а непонятно что.
Тогда зачем в биологии вводили класс млекопитающих? Ведь нет ни одного животного этого класса. Есть коровы, люди, киты и т.п., а млекопитающего нет. Получается и в ООП абстрактные классы не нужны. :-)

модель данныххНет, ошибки не должно быть. В том числе в случае ошибочного имени атрибута.

Типа и на опечатки не реагировать? :-)

модель данныххНо также очевидно, что и отличия между NULL и NotDef тоже не должно быть. Отсутствие свойства и отсутствие присвоенного значения это одно и то же (на уровен модели). Но само собой можно ввести любые спец. значения на уровне приложения.

Если смыслы (причины) отсутствия значения разные, то почему же на уровне модели они должны обозначаться одинаково? Более того есть еще одно спецзнчение, в результате чего скажем булевская логика становится не трехзначной, а пятизначной. :-)


модель данныххДа, здесь модель недоотработана (и очень сильно).

У Вас глаз как у орла. За парой строчек рассмотрели целиком модель данных :-).

модель данныххХуже другое:

- очередная попытка скрестить реляционные и объектные модели. получается эклектично. Например, одновременно и ключи и ссылки.

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

- по идее модель не имеет никакого отношения к РМ - можно транслировать в РМ, а можно в EAV или куда угодно. Поэтому так и не ясно, зачем протаскивать реляционку на уровень объектов.

- сами задачи уже давно неактуальны. Сложные объекты можно легко хранить и обрабатывать в EAV - получается гораздо более гибко, просто и понятно. Вот если бы была аналитика или семантика, то это было бы более актуально. Но для этого тоже надо переосмысливать модель, а когда тут такой якорь как РМ, то ясно, больших сдвигов не приходится ожидать.

Но в целом это не самый плохой подход, тем более, что самому автору нравится (что самое главное). Я бы сказал где-то 45% по направлению к цели. В процессе реализации транслятора и языка наверняка появится много других вопросов.
Понял. Цитировали меня, но пишите не про меня. У нас нет никакой реляционной модели, нет никаких ключей и нет проблем получить назад объекты :-). Да и c семантикой всё нормально, вплоть до того что система поймет и "Количество_колес" и "Number_of_Wheels".

U-geneserg99Не пойму в чем здесь фишка
Раз Вы опять читаете по диагонали, объясню. Для начала ответьте, где я сказал, что чего то восстанавливаю? Вы написали кучу предложений, только потому, что по своему проинтерпретировали мои слова. Ссылки выглядят как направленные, а реально же они работают в обеих направлениях без всяких восстановлений.

Так если они работают в обоих направлениях, зачем же Вы заставляете их выглядеть направленными :-).


U-geneДавайте сначала. Я уже говорил, что речь идет о активных объектах, описываемых и управляемых командами непроцедурного языка. Предположим, что у меня есть класс Ученики. Я его создал в своей схеме данных. Я создал кучу учеников. Эти объекты уже есть, они существуют на сервере (и больше нигде). В какой то момент времени я решил, что мне нужен класс учителей. Я его просто добаляю в схему данных на сервере. Здесь глагол "добавил" не значит, что добавил класс в текст программы, а потом программу перекомпилировал. Я просто выполняю команду, создающую этот класс на сервере, я добавляю его в существующую схему данных. А класс ученики я менять не хочу (хотя могу). Я создаю учителей, добавляю в них ссылки на издавна ссуществующих учеников и могу выполнять по этим ссылкам (фактически в любую сторнону) любые незапланированные запросы из любого клиентского приложения, котором требуются данные об этих объектах. При этом старые запросы (только к ученикам) если таковые использовались в этих любых клиентских приложениях, остаются неизменными.

Не видно с чего это изменились бы запросы к Ученикам, если бы Вы ввели ссылки в Учеников. Так как Учителя к Ученикам по крайней мере 1:N, то получается что для каждого объекта учителя у Вас может задаваться переменное число ссылок. Не очень понятно как это ложится в реляционные таблицы. Теперь если удаляется какой то ученик нужно удалить и ссылку на него в соответствующем учителе (то есть затратить время на ее поиск). Если бы была встречная ссылка, то времени тратить было бы не нужно. Еще сложнее в случае N:N, когда ссылки скорее всего нужно отчуждать от объектов и хранить в отдельной индексированной таблице. Раз индексированная то действует ("медленно положишь"). А если я потом ввожу класс "Школы", ввожу ссылки на соответствующих учителей, а потом учителей удаляю. Как понять в какой школе учится ученик? В общем природу не обманешь :-).

U-geneВ контексте предыдущей ситуации (с добавлением класса Учителя), вам придется менять и класс ученики (что бы ссылки были направлены в обе стороны) и перекомпилировать программу целиком. Кстати, просматривая стандарт ODMG, я не уловил, что в этот момент будет с данными в хранилище.... как они соотнесуться с новым описанием классов. В любом случае, это будет нетривиальный процесс.
У нас мало чего общего с ODMG. Ничего перекомпилировать не нужно. Описания классов в самом хранилище и находятся. А будет ли кто писать новые приложения с учетом добавленных в БД метаданных, и будет ли он писать эти приложения на C# или на ассемблере - это личное дело прикладных программистов.

U-gene2 serg99
Теперь о Ваших средствах_передвижения.

serg99Из "метаданных". Если он сам эти метаданные вводил, то может и просто вспомнить. А если не сам?
Тогда просто смотрит метаданные.

U-geneКстати, тут утверджают
модель данныххНет, ошибки не должно быть. В том числе в случае ошибочного имени атрибута.почему он не прав?

Если имя атрибута не задано ни в одном классе, то это скорее всего опечатка (то есть ошибка). Если имени атрибута нет в тех классах о которых запрос, то либо программист ошибочно полагает что такой атрибут есть в этих классах, либо он ошибочно ищет этот атрибут не в тех классах. То есть опять же ошибка.

U-geneserg99Хотя бы у одного наследника есть "Количество_колес". А если количество_колес есть у разных наследников?
Будет выводить количество колес как обычно. В этом контексте системе всё равно какого класса объект.

U-geneТем не менее к этим млекопитающим (которых по Вашему нет) под конец Вы очень ловко ловко хоботы и ногти в запросах приделаете, которых у "отсутсвующих" млекопитающих изначально тоже нет. Логика железная.
Не очень понятно чем Вы недовольны. "Средства_передвижения" - это обычный абстрактный класс, где скажем может быть задан атрибут "Максимальная_скорость". Если в первоначальным запросе заменить "Количество_колес" на "Максимальную_скорость", то запрос выдаст валидные значения и для автомобилей и для лошадей безо всяких NotDef, так как этот атрибут будет унаследован обоими классами.


Можно конечно в лоб записать как


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