Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 11   вперед  Ctrl      все
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина
...Тогда нужно ясно показать, как любая МД верхнего уровня может использоваться в Вашей, не ориентированной ни на какую конкретную модель СУБД...Нужно просто взять, например, М2 и показать на примере.

Я не буду ничего показывать про Ваши М. Мне - не нужно.


Бредятина
Но, пока, очень важный момент: Вы, все-таки, строго по Дейту делаете - подтвердите еще раз, что класс неизвестной, пока, МД верхнего уровня - это ДОМЕН РМД. То есть, Фамилия Человека, например, - это у Вас класс. Так? А Человек тогда что?

1) Нет у меня МД верхнего уровня.
2) Система строга по Дейту в реляционной проекции, где данные представлены как множество отношения. Но там классов как доменов нет. Там столько скаляры ( то есть данные).
А в проекции, описывается предметная область, нет реляционной модели.Таблицы есть, но это одно их ср-в описание предметной области.

Бредятина
"... При этом используются долговременные таблицы имен, которые тесно связаны с каталогом реляционной машины."
Покажите на примере, пожалуйста.
Зачем? Какой пример, я вообще не понимаю. Оно всё внутри спрятано. Вы ж когда C++ компилятором пользуетесь, Вы ж не думаете, как там таблица имен строится. и вообще про ннее не думаете. Почему это важно?
1 июн 13, 17:36    [14379235]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Basil A. Sidorov
Своей презентацией вы продемонстировали:
а) универсальность реляционных СУБД.
б) практичность реляционных СУБД
Зачем прикручивать к универсальной и практичной вещи некую надстройку, которых уже и так вагончик - лично мне осталось непонятным.
Да. А почти 70 лет истории говорит о том, что фонНеймановские машины так же очень универсальны и практичны. Они принципиально не поменялись за это время, все ими успешно пользуются. Зачем же для них ОО языки придумали? Наверное, что бы было проще ими управлять.

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

Basil A. Sidorov
Что касается декомпозици ...
В основе и ORM-ов и вашего RxO лежит концептуальный прокол - представление о том, что объекты определяют структуру данных.
Отсюда и автогенерация схем и автоматическое построение запросов и аннотации для указания связей и т.п.
Я не утверждал, что объекты определяют структуру данных. Я вообще не фанат абсолютизма, когда начинают все подгонять под одну гребенку (типа "всё - это объекты"). Я лишь говорю, что объекты - полезная штука, которую часто удобно использовать, что бы описывать какую то часть предметной области. Раз удобно - пусть будут. Я и от таблиц не отказываюсь (в прототипе этого нет, мне это очевидным кажется). Хотите -всю предметную область в классах описывайте, хотите в таблицах, хотите - смешивайте. Я уже коллеге Бердятиен написал, что про "концептуальный уровень" я думать не хочу. Есть типы и классы. А раз нет концептуального уровня, то нет и "концептуальных проколов".

Basil A. Sidorov
На самом же деле приложение "видит" данные через призму DML...
.Я подразумеваю, что приложения вообще нет. Вся модель предметной области - на сервере. Клиент - это только интерфейс.
Basil A. Sidorov
..., а отображение этих самых DM на объекты - вторично, т.к. сильно зависит от семантики.
... и семантика вся на сервере. И все операции с данными на сервере (в т.ч.запросы, групповые операции) - в терминах этой семантики.

Basil A. Sidorov
Нужно просто принять как факт, что реляционная алгебра - проста. И научиться решать реляционные задачи точно так же,
как в школе решались квадратные уравнения.
Фон-неймановская машина тоже проста. Но прикиньте что будет, если Вы скажете "линейная память устроена очень просто. Надо декомпозировать данные до отдельных ячеек памяти и это будет проще чем квадратые уравнения, это ж вообще как 2+2. Поэтому давайте вместо ОО использовать старый добрый ассемблер". (это ваша фраза, переделанная для систем с линейной памятью). Думаю, вас не поймут с такой инициативой.

Дело в том, что и "2+2" и "квадратные уравнения" - это всего лишь инструмент. Чем проще инструмент, тем сложнее его использовать для решения сложных задач. Наоборот, сложный инструмент позволяет упростить решение задач.

И я, честно, вообще не понимаю, в чем Вы меня упрекаете, касательно "реляционной алгебры" :) Я взят понятия и операции формальной реляционной модели и пользуясь только ими построил ОО транслятор для формальной реляционной машины. Можно это рассматривать как одну из реляционных задач. Получилась объектно-ориентированная система управления реляционными БД. Алгебра это никуда не делась. Она активно используется внутри и может быть использована снаружи.
1 июн 13, 18:43    [14379325]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
mad_nazgul
В ООП приятно и просто моделировать все что угодно.
Просто когда начинают проектировать модель данных, то почему-то забывают.
Что одна модель данных может быть для нескольких моделей ПО (предметной области).
И пытаются перетащить модель данных в ООП.
Что приводит к плачевным последствиям.

PSV100
Имхо, это происходит от того, что об ООП не думают как об объектно-ориентированном проектировании, на мозги давит объектно-ориентированное программирование, причём в трактовке мейнстрима, с многоуровневым наследованием, в т.ч. и реализации.

Basil A. Sidorov
Давит причём не на мозги, совсем другое - реальная жизнь со всеми её исключениями из правил и нестыковками.

U-gene
Я не утверждал, что объекты определяют структуру данных. Я вообще не фанат абсолютизма, когда начинают все подгонять под одну гребенку (типа "всё - это объекты"). Я лишь говорю, что объекты - полезная штука, которую часто удобно использовать, что бы описывать какую то часть предметной области. Раз удобно - пусть будут. Я и от таблиц не отказываюсь (в прототипе этого нет, мне это очевидным кажется). Хотите -всю предметную область в классах описывайте, хотите в таблицах, хотите - смешивайте. Я уже коллеге Бердятиен написал, что про "концептуальный уровень" я думать не хочу. Есть типы и классы. А раз нет концептуального уровня, то нет и "концептуальных проколов".


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

В соседней теме обсуждались мейнстрим-инструменты для разработки БД. Там была ссылка на "эталонные" примеры ER-моделей. Вот аналитики и проектировщики ваяют эти модели, где встречается дублирование одних и тех же таблиц ("клиенты", "сотрудники", "запасы" и т.д.), часто эти таблицы имеют разный состав полей согласно логике конкретной ER-модели (причём мейнстрим может преподносить эти модели как модели прикладной области).

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

Далее эти модели кидают программистам или тем, кто непосредственно возится с БД. Они начинают чесать репу над тем, чего же там напроектировали, и думать, как эти одинаковые таблицы по моделям слепить как одна физическая таблица (или уже потребуется разделять данные по связанным разным таблицам, что вообще мимо "моделей"). У них уже нет средств проектирования для этого (а точнее, уже всё "напроектировали"), "эталонный" ErWin и пр. дают свой макроассемблер и говорят программистам мол "гибко" выкручивайтесь.

Теперь нужно выкручиваться тем, кто работает с клиентским кодом через ООП. Могут быть варианты:

- для каждого модуля/подпроекта создаётся свой класс-обвёртка над таблицей, например, "сотрудники", каждый класс содержит свой набор полей (большая часть которых дублируется), нужный для конкретной задачи. При изменении таблицы нужно переделывать некоторые или все классы;

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

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

Короче говоря, вполне реально ынтырпрайз-ООП может вынудить плюнуть и слепить единый универсальный класс для таблицы для всех случаев с единым общим набором полей (или сделать его базовым с protected-данными, затем лепить целевых потомков, лишь публично объявляя нужные поля). И плевать на то, что в ряде случаев в коллекциях будут неиспользуемые данные, это проблемы тех, кто будет оптимизировать через ынтырпрайз-железо.


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

И в рамках ынтырпрайза какой-то поставщик объектного расширения к СУБД может запросто вынудить использовать свой продукт, сам реализовав его уже поверх своего EAV, да ещё подкрепив его обязательными глобальными ID для всех объектов, могут ещё и в виде какого-то GUID (т.е. рядом с возможными естественными ключами будут и ID) и т.д. и т.п. Все оптимизации только "железные".

В общем, с одной стороны через мейнстрим-ООП пытаются дать возможность для упрощения на каком-то уровне (причём не в самом лучшем виде), но, с другой, вся исходная сложность системы и многообразие никуда не делись, их выталкивают в сторону, мол сами разбирайтесь.
1 июн 13, 21:26    [14379689]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Писал, но куда то ответ делся. Пишу заново.
PSV100
Спасибо за презентацию проекта.
Пожалуйста.


PSV100
Имеются в виду не политические вопросы, а реальные технические проблемы. Непонятно, как будет функционировать продукт.
Я вижу это как расширение SQL сервера. То есть, все что есть в РСУБД сейчас, сохраняется, появляются несколько новых команд. Все остальное полумеры.

PSV100
Предполагаю, что это какой-то "sql-сервер" как прослойка к настоящему серверу СУБД…. Или же это какой-то… Или есть ли какая-то технология выше….Или это только прототип возможного языка на "сервере" ?
В видео – прототип, конечно. Но он реализует базовую идею? Без которой никак. А дальше, сверху, по существующей схеме данных, можно генерировать визуальные или программные интерфейсы.

PSV100
Насколько реально возможна трансформация жизненно необходимого исходного SQL ?
Не думаю что это нужно или полезно. Если есть возможность ()а возможность есть) надо сохранять, что бы обеспечить обратную совместимость. Что бы можно было, накатив новую версию СУБД (например MS SQL 2022 :) ), ничего н потерять и получить новые возможности (в тч в существующих БД).

PSV100
Есть ли возможность оперировать, скажем, рекурсивными запросами.
1) WITH никуда не девается. 2) Для классов тоже можно сделать рекурсию, В прототипе нет; идея как сделать эту рекурсию, понятна…. А, вообще, про рекурсию постоянно спрашивают
PSV100
Ну, например, если я применю одно объектное выражение, которое заставит систему генерировать sql с подзапросами, а если по-другому - получим соединение таблиц (это, конечно, всё условно, я понимаю, что об оптимизации заботятся изначально). Или есть ли какая-то лазейка для прямой спасительной sql-инъекции, если система чего-то не может.
Насчет лазейки – запросто. :) Это как в С++ блок "asm". В целом вопрос очень важный, но смысл им заниматься появляется только тогда, когда дойдем до конкретной реализации на в СУБД.

PSV100
…Есть ли какие-то технологии, облегчающие жизнь. Например, как-то так: …
Я думал в этом направлении про XML.
UPDATE <класс>[<какое-то where>] SET XMLexpression;

PSV100
- Насколько развита ООП-технология как такоЕсли конроль типов выборку ва ?
Входной язык в части ОО команд можно накручивать как угодно.
PSV100
Есть ли механизм "виртуальных вызовов". Например, пусть я сформирую выборку из объектов разных классов (подклассов) (пока даже не знаю как, возможно, через какой-то "union"), и укажу выполнить метод как-то так: "FOR <выборка> EXEC <метод>", и соответственно я должен ожидать то, что для каждого объекта будет "выполнен" корректный метод нужного класса. И пр.
Можно…наверно. :) Во всяком случае, я пока не вижу причин, почему нельзя.

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

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


Это большой разговор.
1)В принципе можно было бы сказать, "ребята, ничего не знаю, в системе такая штука такая возможна, а уж как вы ее применять или понимать будете – не моя забота." :) Это я про множественное наследование.
2)Я и не пытаюсь решить ни вопросы ООП ни вопросы реляционных систем. Там тоже есть много чего, взять хотя бы трехзначную логику, которую не все любят. И все эти вопросы прямиком шуруют в мою систему.
3) Вообще ООП в традиционном понимании плохо подходит для СУБД. Например, создадим мы объект "сотрудник", а этот сотрудник завтра менеджером станет. А у нас менеджеры в отдельном подклассе. В традиционном понимании ООП вообще не ясно что делать, потому что объекты к одному и тому же классу принадлежат от создания до уничтожения и других вариантов нет; соответственно надо объект уничтожить и другой создать. А в нетрадиционном, можно существующий объект "сотрудник" просто подвинуть по иерархии наследования до менеджера. Ничто не мешает и никакой типизации это не вредит.
2 июн 13, 01:40    [14380105]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
PSV100
Очень плохо, что у ынтырпрайза и нет "концептуального уровня", он и не пытается дать методологию для моделирования, приближённую к реальной жизни. (и дальше, много)....
Вы здесь , КМК, схему данных и модель данных попутали. То. что я принципиально отказываюсь от концептуальной модели (от лозунгов типа "всё - объекты" или "все отношения", или от М-моделей от коллеги Бредятина), вовсе не значит, что у меня нет схемы данных. Она есть, она определена в любой момент, ее обязательно можно будет менять.
2 июн 13, 01:48    [14380116]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11466
U-gene
Да. А почти 70 лет истории говорит о том, что фонНеймановские машины так же очень универсальны и практичны. Они принципиально не поменялись за это время, все ими успешно пользуются. Зачем же для них ОО языки придумали? Наверное, что бы было проще ими управлять.
ОО-абстракция - практична. В частности тем, что для неё есть простая структура данных. Отличающаяся в деталях для разных языков и даже для разных реализациях одного языка, но есть.
Практичность высокоуровневых абстракций структурного и объектного программирования обусловлена тем, что разработчику не нужно опускаться до уровня ассемблера. Нет, разработчик по-прежнему должен разбираться в эффективности кода, но вот кода этого становится в разы или даже на порядки меньше.
В вашей абстракции такой структуры нет, поэтому рано или поздно окажется, что режим автоматического сопоставления объектов с нижележащим слоем хранения не позволяет эффективно реализовать те связи, которых нет в объектной модели и придётся работать с таблицами, ключами, индексами и запросами. Вот это и есть - "не летает".
Я не утверждал, что объекты определяют структуру данных.
Сказавши "а", произнеси и "б".
Структура данных есть, т.к. без этого невозможно использовать нижележащее хранилище.
Если структуру определяют не объекты, тогда что? Ещё одна стройная система костылей и подпорок?
Я подразумеваю, что приложения вообще нет. Вся модель предметной области - на сервере.
А сервер, значит, святых духом эту модель обрабатывает?
Я взят понятия и операции формальной реляционной модели и пользуясь только ими построил ОО транслятор для формальной реляционной машины.
Правила ссылочной целостности в вашем ОО-трансляторе как определяются? Как отношения строятся?
И BNF есть?
2 июн 13, 04:40    [14380174]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
PSV100
Member

Откуда:
Сообщений: 157
U-gene
Вы здесь , КМК, схему данных и модель данных попутали.
...

Это не только я попутал. Тут сами мейнстрим-стандартизаторы направо и налево всё путают. Одни, кто производит инструменты для ER-моделирования, кричат, что ER-модели и есть ваша предметная область, от неё нужно дышать. Другие, кто имеет уже полный стек UML-моделирования, отсылают к моделям классов, компонент и пр. как к первичной песни и т.д. В общем, фиг с ним, с этим мейнстрим-болотом.

Спасибо за ответ. Кроме презентации я посмотрел и "бумажные" сочинения, в целом, картина прорисовалась.

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

Правильно ли я понимаю смысл db-класса и наследования?

Пусть есть класс "сотрудники", у него есть два потомка - "менеджеры" и "уборщики". Данные, записанные непосредственно в "сотрудники" не должны быть видны из потомков, также "менеджеры" не должны видеть "уборщиков" и наоборот. Но через класс "сотрудники" мы должны видеть всех или нет? (т.е. непосредственно "сотрудников" и всех "потомков"). Или как состыковывать данные, когда создаётся объект "менеджер" и его также нужно зафиксировать в "сотрудниках" ?

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

Также не хватает понятие модулей (пакетов, областей имён и т.п.) с интерфейсами (т.е. объявления публичности, private/public элементов).

Теперь я попытаюсь спроектировать модуль XX и YY, которые имеют общий класс CCC. Если класс - это непосредственная коллекция объектов, то создавая классы в каждом модуле как XX.CCC и YY.CCC (по мотивам того, как учат делать ER-схемы данных в рамках логической модели), то я сделаю независимые коллекции, когда мне нужно единое хранилище, для многих задач (причём, как бы с разным составом полей для каждого логического модуля). Тогда мне нужен, ну... пусть отдельный модуль ZZ, с общим функционалом для многих других, где я в т.ч. сделаю общий класс ZZ.ССС. Теперь в модулях XX и YY я сделаю потомков от этого класса, XX.CCCxx и YY.CCCyy. Но, для меня до конца не понятна концепция класса, вроде как класс означает физическое (а также и некое логическое по отношению к потомкам) хранилище. Поэтому вроде как нужно эти классы убрать (или не вводить) из XX и YY. Но мне нужно как-то отразить, что в модели каждого этого модуля используется (или является частью) общий класс ZZ.ССС. Т.е. нужны какие-то декларации вида "USING ZZ.CCC (<список полей>)", где опционально можно задать список полей (и методов), используемых в модуле, плюс "алиасы" для имён и пр.

Одним словом, до конца не ясна концепция класса.

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


Тут, всё таки, нужно подметить особенность типового мейнстрим-ООП: начинается всё с простых классов, затем может появится понятие private/public/virtual и пр. наследование, абстрактные классы и интерфейсы, "методы-расширения", а то и traits с mixin, или даже "case"-классы с implicit-элементами и т.д.


P.S. Собственно, меня проблематика интересует не столько с позиции целесообразности или возможности полной замены SQL, а больше сам концептуальный взгляд на проектирование и моделирование в подобной системе как RxO.
2 июн 13, 16:07    [14380644]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Я не буду ничего показывать про Ваши М. Мне - не нужно.

Покажите про любую свою.
Вы написали: "... в предлагаемых структурах могут быть практически напрямую выражены любые эти М - какую хотите, ту и используйте."
Что значит "мне не нужно"??? Зачем начали пояснять что-то, а по существу не хотите говорить?))
U-gene
1) Нет у меня МД верхнего уровня.

Этого просто не может быть, я уверен. Докажите это - продемонстрировав описание той же самой примитивной "задачи", которая использовалась для сравнения моделей верхнего уровня. Опровергните всю ту тему, показав, что эта задача решается в Вашей системе без всякой МД верхнего уровня. Но при этом, и просто РСХОД (можете для удобства использовать некорректный термин РСУБД) применять почему-то хуже, чем Вашу систему + РСХОД. Вот на этом совсем простом примере и поясните. Или напишите (как это обычно делают): "На таком простом примере невозможно продемонстрировать суть предлагаемой технологии".
U-gene
2) Система строга по Дейту в реляционной проекции, где данные представлены как множество отношения. Но там классов как доменов нет. Там только скаляры (то есть данные).
А в проекции, в которой описывается предметная область, нет реляционной модели.Таблицы есть, но это одно из средств описания предметной области.

Я правильно исправил ошибки в Вашем тексте???
Итак, в проекции предметной области нет РМД и нет никакой другой модели! Как же описывается предметная область? Какие элементы описания (если бы МД была, это были бы элементы структуры этой МД - первый аспект МД) используются?
Далее, Вы пишете, что Ваши классы используются как домены этих таблиц. А что же представляют собой эти таблицы? В РМД отношения представляют и сущности и связи между сущностями. А связи в свою очередь, моделируются, то с помощью отношений, то с помощью ключей.
13755686
14020991
Это и есть одна из причин того, что РМД не удалось еще никому применить для решения какой-либо задачи, то есть, приходится использовать архитектуру "МД верхнего уровня+маппинг+РМД". Вероятно, "Ваша система+РСХОД" как раз и делает возможным применение РМД для практических задач без использования МД верхнего уровня и маппинга по всем трем аспектам МД. Так проясните этот важный вопрос))
U-gene
Зачем? Какой пример, я вообще не понимаю. Оно всё внутри спрятано. Вы ж когда C++ компилятором пользуетесь, Вы ж не думаете, как там таблица имен строится. и вообще про нее не думаете. Почему это важно?

Выше про пример написал подробно. И про то зачем он нужен. Чтобы понять - как Вы обходитесь без моделирования данных.
2 июн 13, 16:54    [14380700]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Хотите -всю предметную область в классах описывайте, хотите в таблицах, хотите - смешивайте. Я уже коллеге Бердятине написал, что про "концептуальный уровень" я думать не хочу. Есть типы и классы. А раз нет концептуального уровня, то нет и "концептуальных проколов".

Вы же писали, что "мои классы - это домены таблиц"? Теперь говорите, что всю предметную область можно описать доменами таблиц (без использования таблиц)??? Вот почему так важен простейший пример))
2 июн 13, 16:59    [14380708]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
То. что я принципиально отказываюсь от концептуальной модели (от лозунгов типа "всё - объекты" или "все отношения", или от М-моделей от коллеги Бредятина), вовсе не значит, что у меня нет схемы данных. Она есть, она определена в любой момент, ее обязательно можно будет менять.

Нет, Вы отказываетесь не от концептуальной модели, а именно от логической МД верхнего уровня)) Поэтому и нужно пояснить на примере...
2 июн 13, 17:02    [14380717]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
PSV100
...Одним словом, до конца не ясна концепция класса...

Дейту ясна. См. про первую грубейшую ошибку.
2 июн 13, 17:06    [14380724]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Максим Н
С EAV это конечно возможно, но запросы будут гораздо сложнее, их тяжело поддерживать и оптимизировать. Не все радужно с индексированием.



Тут же все просто.
С EAV это возможно, без EAV это невозможно.

Использовать XML в реляционной субд - это путь в никуда, зачем тогда тебе реляционная субд? Бери XML-хранилище какое-то.
2 июн 13, 20:48    [14381141]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Максим Н
Member

Откуда: Екатеринодар
Сообщений: 1439
MasterZiv
Максим Н
С EAV это конечно возможно, но запросы будут гораздо сложнее, их тяжело поддерживать и оптимизировать. Не все радужно с индексированием.



Тут же все просто.
С EAV это возможно, без EAV это невозможно.

Использовать XML в реляционной субд - это путь в никуда, зачем тогда тебе реляционная субд? Бери XML-хранилище какое-то.


XML уже в прошлом, я просто упомянул это решение (пусть плохое и не подходящее) как одно из альтернатив для EAV. Сейчас смотрю в сторону графов.
2 июн 13, 21:31    [14381249]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
MasterZiv
С EAV это возможно, без EAV это невозможно.
Главное не путать слова «не умею» и «невозможно». Есть куча систем реализовпвших гибкость (и даже с наследованием) без EAV.
2 июн 13, 21:34    [14381253]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Максим Н

XML уже в прошлом, я просто упомянул это решение (пусть плохое и не подходящее) как одно из альтернатив для EAV.

Может XML - пусть плохое и не подходящее, но все таки в отличии от EAV относится к полноценным типам МД - свои средства структурирования, язык запросов. У EAV все это от РМД: т.е. как бы типа плохая РМД.
В частности, есть вроде СУБД ХML.
2 июн 13, 22:25    [14381372]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Basil A. Sidorov
U-gene
Да. А почти 70 лет истории говорит о том, что фонНеймановские машины так же очень универсальны и практичны. Они принципиально не поменялись за это время, все ими успешно пользуются. Зачем же для них ОО языки придумали? Наверное, что бы было проще ими управлять.
ОО-абстракция - практична. В частности тем, что для неё есть простая структура данных. Отличающаяся в деталях для разных языков и даже для разных реализациях одного языка, но есть.
Практичность высокоуровневых абстракций структурного и объектного программирования обусловлена тем, что разработчику не нужно опускаться до уровня ассемблера. Нет, разработчик по-прежнему должен разбираться в эффективности кода, но вот кода этого становится в разы или даже на порядки меньше.
В вашей абстракции такой структуры нет, поэтому рано или поздно окажется, что режим автоматического сопоставления объектов с нижележащим слоем хранения не позволяет эффективно реализовать те связи, которых нет в объектной модели и придётся работать с таблицами, ключами, индексами и запросами. Вот это и есть - "не летает".
Вы сейчас сами с собой спорите, и я Ваши переходы от одной мысли к другой уловить опять не могу. Но по отдельным кускам пройтись смогу.
1) "ОО- абстракция практична." То есть ею пользоваться проще и удобнее. Ну а я о чем?
2) "кода этого становится в разы или даже на порядки меньше." - и опять тоже самое
3) "В вашей абстракции такой структуры нет"... какой структуры нет? Вы презентацию видели? Структура объектов четко описана.
4) "рано или поздно окажется, что режим автоматического сопоставления объектов с нижележащим слоем хранения не позволяет эффективно реализовать те связи" - не окажется,ни рано ни поздно. Какую бы сложную структуру объектов мы не описали ("в пределах RxO") она всегда будет достаточно эффективно транслироваться в описание структур реляционной машины. Потому язык изначально построен так, что бы эффективно транслироваться, вместе с ключами индексами и запросам.


Basil A. Sidorov
Basil A. Sidorov
В основе и ORM-ов и вашего RxO лежит концептуальный прокол - представление о том, что объекты определяют структуру данных.
Я не утверждал, что объекты определяют структуру данных.
Сказавши "а", произнеси и "б".
Структура данных есть, т.к. без этого невозможно использовать нижележащее хранилище.
Если структуру определяют не объекты, тогда что? Ещё одна стройная система костылей и подпорок?
Вы первое предложение абзаца прочитали, и сразу в бой? хорошо, специально для Вас постараюсь уместить свою мысль в одно предложение. Я не утверждал, что только объекты определяют структуру данных, как это Вы имели в виду в Вашем предыдущем посте, о чем Вы видимо уже забыли.

Basil A. Sidorov
Я подразумеваю, что приложения вообще нет. Вся модель предметной области - на сервере.
А сервер, значит, святых духом эту модель обрабатывает?
Нет. Посредством детерминированного алгоритма.

Basil A. Sidorov
Правила ссылочной целостности в вашем ОО-трансляторе как определяются? Как отношения строятся?
И BNF есть?
Ну здравствуйте! :) Ну а как Вы себе представляете создание транслятора без BNFа ? :) Определяются и строятся,здесь все прописано. И ссылки и внешние ключи в примере презентации есть.
4 июн 13, 15:17    [14389470]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11466
U-gene
Какую бы сложную структуру объектов мы не описали ("в пределах RxO") она всегда будет достаточно эффективно транслироваться в описание структур реляционной машины.
Ладушки.
Можно увидеть пример описания RxO, функционально эквивалентный отношению "многие ко многим" для задачи "студенты и предметы"?
4 июн 13, 16:12    [14389930]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Бредятина
Вы написали: "... в предлагаемых структурах могут быть практически напрямую выражены любые эти М - какую хотите, ту и используйте."
Я дальше написал, что не настаиваю и спорить не буду.Еще раз могу это повторить.
Бредятина
U-gene
1) Нет у меня МД верхнего уровня.

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

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

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

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

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

Например Дейт , говоря о первой серьезной ошибке, рассматривает два варианта того, как соотносятся ОО и Р концепции
класс = домен
класс = отношение.
А RxO (даже в прототипе) реализует принцип, согласно которому данные множества классов представлены в виде множества отношений ("объектных видов"), и эти множества соотносятся связью M:N, то есть данные из одного класса могут быть представлены во множестве объектных видов, а один объектный вид может представлять данные из множества классов. Объектное описание ортогонально реляционному представлению, и единственное что их связывает - общие имена. Этот принцип ни в с одним из вариантов Дейта никак не соотносится. Дейт не то, что не прав, но не полон. С учетом того, что эта неполнота наблюдается в исходном посыле, я не даже не рассматриваю все его дальнейшие выводы о том, какое решение может бытьправильным, как критерий истины. А в том, какое решение будет неправильным он, конечно, прав, как и во многом другом. Так же как и Вы. :)
4 июн 13, 16:53    [14390308]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Basil A. Sidorov
U-gene
Какую бы сложную структуру объектов мы не описали ("в пределах RxO") она всегда будет достаточно эффективно транслироваться в описание структур реляционной машины.
Ладушки.
Можно увидеть пример описания RxO, функционально эквивалентный отношению "многие ко многим" для задачи "студенты и предметы"?
Я всех задач наизусть не помню, к сожалению. Детализируете, пожалуйста.
4 июн 13, 16:59    [14390347]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11466
U-gene
Я всех задач наизусть не помню, к сожалению. Детализируете, пожалуйста.
Есть несколько студентов и несколько предметов.
Каждый студент должен выбрать несколько предметов.

P.S. Где, простите, появилась альтернативная реальность с новым толкованием отношения "многие ко многим"?
4 июн 13, 17:03    [14390366]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
PSV100
Но, всё таки, вопрос на счёт концептуального уровня до конца не ясен. Конечно, сейчас есть только прототип, много чего ещё не реализовано, я не в курсе того, что запланировано, и, в целом, много чего не знаю (и всяческих деталей изложенных материалов уже не помню). Поэтому, я могу ошибаться, но хотелось бы понять, как организовать проектирование в RxO.
Я пока не готов ответить в деталях. Но в общем, если рассматривать методы "сверху-вниз" и "снизу вверх", то вырисовывается какое-то "навстречу" :).
PSV100
Правильно ли я понимаю смысл db-класса и наследования?
Да. И все остальное. Атрибуты и методы вместе, их специффкация отделена от реализации (для меня это = инкапсулировано), эту реализацию можно переопределять (полиморфизм), итд.

PSV100
Пусть есть класс "сотрудники", у него есть два потомка - "менеджеры" и "уборщики". Данные, записанные непосредственно в "сотрудники" не должны быть видны из потомков, также "менеджеры" не должны видеть "уборщиков" и наоборот. Но через класс "сотрудники" мы должны видеть всех или нет? (т.е. непосредственно "сотрудников" и всех "потомков"). Или как состыковывать данные, когда создаётся объект "менеджер" и его также нужно зафиксировать в "сотрудниках" ?.
Не очень понял. Объекты класса наследника являются объектами родительского класса, но не наоборот. Родительский класс включает объекты дочерних классов, но не наоборот.

PSV100
Кстати, получается, что класс автоматом означает наличие "коллекции" объектов, т.е. для любого класса можно заполнять его объектами, даже если он некий технический, невыражающий конечную прикладную сущность, используется как обобщение кода для наследования. Здесь можно попробовать уменьшить противоречия в ООП, и дать правило, что класс это всегда "коллекция" (что и есть), подкреплённый понятием субтипа (некие субколлекции). Тогда есть потребность в дополнительном механизме для обобщённого кода. Например, структурные множества "SET OF" можно иметь не только встроенными в класс, но и внешние независимые (типа "CREATE SET ..."), затем их можно подключать в классы (не через наследование).
Можно. Это языковые штуки.

PSV100
Также не хватает понятие модулей (пакетов, областей имён и т.п.) с интерфейсами (т.е. объявления публичности, private/public элементов)....
Это КМК полезные штуки, которые тоже можно реализовать.
4 июн 13, 17:53    [14390609]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Схематично
Вариант с классами (доступен сейчас)
CLASS ПРЕДМЕТЫ
{
...
}

CLASS СТУДЕНТЫ
{
...
изучает SET OF
{
предмет ПРЕДМЕТЫ
...
} КEY предмет
}

В полной реализации, когда будут доступны таблицы, можно воспользоваться ими
CLASS ПРЕДМЕТЫ
{
...
}

CLASS СТУДЕНТЫ
{
...
}

ТABLE Изучает
{
предмет ПРЕДМЕТЫ
студент СТУДЕНТЫ
} КEY (предмет, студент)


PS на PS. В презентации классы GOODS и SHIPMENTS связаны отношением многие-ко-многим. Я подумал, что раз Вы это не заметили, то может быть "альтернативная реальность" у Вас, поэтому уточнил.
4 июн 13, 18:10    [14390674]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11466
U-gene
Вариант с классами (доступен сейчас)
...
А как реализуется разрешение или запрет каскадного удаления предметов?
Скажем, вуз решил сократить непопулярную дисциплину?
В полной реализации, когда будут доступны таблицы, можно воспользоваться ими
И чем этот вариант лучше изучения одного или нескольких SQL-диалектов?
Я подумал, что раз Вы это не заметили, то может быть "альтернативная реальность" у Вас, поэтому уточнил.
Вы преподавали?
Анекдот про "я им два часа объяснял, уже сам всё понял, а до них так и не дошло" - знаете?
Презентация не лучший, мягко говоря способ излагать основы.
4 июн 13, 18:23    [14390718]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Я дальше написал, что не настаиваю и спорить не буду. Еще раз могу это повторить.

И я сразу написал, что не нужно ни настаивать, ни спорить. Я же не спорю. Я попросил пояснить, всего лишь.
U-gene
Ок, давайте скажу по другому. Когда я говорю про свою систему я не думаю про какую-либо модель. Я предлагаю
-- простую систему типов, которую пользователь может использовать для описания предметной области (назовем это входной системой типов) и
-- простой переход к реляционному представлению данных о предметной области, описанных с использованием этой системы типов, с сохранением семантики данных (точнее даже, на основе этой семантики).

Пока, можно только гипотетически предположить, что система типов выполняет роль отношений РМД...
U-gene
При этом входная система типов включает и классы и таблицы. (в прототипе только классы? табличные структуры обсуждаются)

По Дейту (а Вы подтвердили, что делаете по Дейту) класс - это домен (то есть, класс не соответствует отношению РМД). И Вы говорили ранее о доменах таблиц. Но самих таблиц нет. Каким же образом, набор свойств типа сущности (при том, что нет никаких типов сущности) становится неким отношением в РМД? Ведь простейший пример использовался в теме по ссылке. Почему нельзя на нем пояснить?
U-gene
-- Классы очень похожи на то, что существует в традиционных ОО языках. Единственное условие - состояние объекта описывается набором значений типов, допускающих реляционное присваивание. То есть, атрибутами объектов могут быть скаляры, кортежи и назовем это "табличные атрибуты" ТА (в прототипе только скаляры и ТА). Это условие - залог оптимальной трансляции структур. Все объекты уникальны по определению, но в классе для объектов могут быть заданы явные ключи. Связи между классами могут быть определены как с использованием ссылок, так и внешними ключами

Итак, Вы допускаете первое серьезное заблуждение, все-таки?????
U-gene
-- Таблицы похожи на реляционные таблицы. Единственное отличие заключается в том, что я могу классы, которые есть множества объектов, использовать как домены таблиц (более строго, доменом являются множество ссылок на объекты класса). Кроме того, классы и таблицы могут быть связаны внешними ключами.

Здесь опять по Дейту)) Он и не отрицает, что значением атрибута отношения может быть значение переменной отношения...
U-gene
И когда я гляжу на эту входную систему типов и сравниваю ее с Вашими М-моделями, я не вижу вариантов, где ваши сущности и/или связи не могли бы быть напрямую выражены с использование моих классов и/или таблиц, и возможных связей между классами и/'или между' таблицами.

Уже не я один, как видите, просит Вас рассмотреть пример, рассмотренный в теме по ссылке (точнее, пример аналогичного класса).
Что сложного в использовании М2 для этого примера?
U-gene
Вообще, во всех разговорах и спорах о "моделях" обычно рассматриваются какие то универсальные штуки, позволяющие и описать предметную область и представить данные о предметной области. А я предлагаю не модель, а очень простой способ перехода от достаточно произвольного описания предметной области (классы + таблицы) к реляционному представлению данных о этой предметной области.

Чем именно "достаточно произвольное описание предметной области" отличается от логической МД? Давайте остановимся на аспекте структуры. Он же есть, правильно? Вы хотите, в частности, сказать, что связи между типами сущностей моделируются с помощью классов и таблиц, подобно тому, как в РМД они моделируются при помощи отношений и ключей.
U-gene
Я в детали Ваших М-моделей я влезать не хочу. Ну...вдруг это перечень не полный? Я начну его по пунктам анализировать, а окажется Вы что-то упустили. Нет, не буду :)

Никто же не просил Вас ничего анализировать. Ни спорить, ни настаивать, ни анализировать. Просто взять М2, банальный пример из темы, и показать как это делается в Вашей системе.
U-gene
Например Дейт , говоря о первой серьезной ошибке, рассматривает два варианта того, как соотносятся ОО и Р концепции
класс = домен
класс = отношение.
Дейт считает, что класс = домен.

U-gene
А RxO (даже в прототипе) реализует принцип, согласно которому данные множества классов представлены в виде множества отношений ("объектных видов"), и эти множества соотносятся связью M:N, то есть данные из одного класса могут быть представлены во множестве объектных видов, а один объектный вид может представлять данные из множества классов.

А Вы так не считаете. Это понятно. И теперь еще актуальнее становится пример описания предметной области в Вашей логической МД, которой. как бы, нет))
U-gene
Объектное описание ортогонально реляционному представлению, и единственное что их связывает - общие имена.

Приведите пример!!!)))
U-gene
Этот принцип ни в с одним из вариантов Дейта никак не соотносится. Дейт не то, что не прав, но не полон. С учетом того, что эта неполнота наблюдается в исходном посыле, я не даже не рассматриваю все его дальнейшие выводы о том, какое решение может бытьправильным, как критерий истины. А в том, какое решение будет неправильным он, конечно, прав, как и во многом другом. Так же как и Вы. :)

Это никак не объясняет, почему на уровне хранения МД есть, а на уровне описания предметной области никакой МД нет. Вероятно, Вы считаете, что МД нет, потому что нет второго и третьего аспектов? ОЦ и манипулирования? Это как же так?
В РМД ведь тоже нет ни сущностей, ни связей между ними, но это же не означает, что РМД не МД...
4 июн 13, 19:57    [14391020]     Ответить | Цитировать Сообщить модератору
 Re: Хранение данных с гибкой структурой и запросы к ним  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
U-gene
Схематично
Вариант с классами (доступен сейчас)
CLASS ПРЕДМЕТЫ
{
...
}

CLASS СТУДЕНТЫ
{
...
изучает SET OF
{
предмет ПРЕДМЕТЫ
...
} КEY предмет
}

Это детально раскритиковано, в том числе и Дейтом. Несимметричный доступ. _мод так тоже делает в своей системе (см. тему про МД верхнего уровня).
U-gene
В полной реализации, когда будут доступны таблицы, можно воспользоваться ими
CLASS ПРЕДМЕТЫ
{
...
}

CLASS СТУДЕНТЫ
{
...
}

ТABLE Изучает
{
предмет ПРЕДМЕТЫ
студент СТУДЕНТЫ
} КEY (предмет, студент)


Поясните, пожалуйста, почему конкретно не может быть (а это же очевидно из Вашего примера, что не может быть)
CLASS Изучает
?
4 июн 13, 20:06    [14391038]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить