ModelRНе понял, каим образом в принципе можно отказаться от обмена данными между БД и приложением? Имеется в виду те объекты приложения, данные о которых храняться в РБД. Клиентское приложение конечно есть. Но вся предметная область описана в БД. То есть это получается уже и не сервер БД, а сервер, обеспечивающий существования объектов, описывающих предметную область.

И хде это такое? Нибось в М каком-нить?
Чур меня, чур...... тьфу, тьфу, тьфу... примерещится же такое.;))) Но...ждемс......

НРМА можно нескромный вопрос: как реализовать НРМ ?

А что же здесь нескромного то?:) В НРМ две части.Вторая часть так и называется...

НРМv1.09стр25...Часть 2. R*O система изнутри. Возможная реализация...

модЗдесь возможны варианты
1)...
2)...
Вы, часом, не про эти ли варианты ?

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

Вчитался в Ваш вопрос модСтруктура хранения фиксируется и все классы хранятся в фиксированном наборе таблиц БД... Вы где-то что-то явно недопоняли, иначе у Вас такое предположения даже бы и не вознгикло.

В общем да. Правильней сказать - изменение спецификации компонента объектного типа естественно ведет к изменению его реализации. Если компонент реализован как хранимый, то изменение его структуры ведет к изменнию таблицы, реализующей это хранение.

....:) и все таки это Вы не так поняли - потому как предложили попробовать рассмотреть второй вариант, где "структура хранения фиксируется". ИМХО EAV который является "одним из способов такой фиксации", сводит возможности реляционных систем к достаточно тупому хранению множества простых значений. Это как например взять обои с хорошим рисунком, покрошить их на мелкие квадратики и потом этими квадратиками стены обклеить - и это все потому, что квадратики легче клеем намазывать :)

мод...как быть с наследованием - ведь старые методы (программы) должны работать с новыми таблицами и без перетрансляции...
...ИМХО это ваши персональные фантазии на заданную тему :)... Какие старые методы? какие новые программы? Вы о чем?

2 okdoky

авторВаши ответы очень абстрактные
А прочитать статью то - что не судьба? Там достаточно конкретно описаны принципы, по которым система должна реализовываться...

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

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