Lift Два.Ноль

>1) чтобы умники со схемой в коде не писали в БД мусор;

А что тут такого?

Я понимаю зачем нужны жесткие соглашения в задачах связанных с затамайнингом - я не понял зачем на быдлосайте при вводе года рождения чтоит жесткий критерий «число». Чтобы схему удовлетворить?

2) чтобы работал SQL.

Ты имеешь ввиду запросы условия вида obj.field == value? А зачем для этого жесткая схема?

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

Как раз в датамайнинге жесткие ограничения не очень нужны - данные статичны.

я не понял зачем на быдлосайте при вводе года рождения чтоит жесткий критерий «число».

O_O

Чтобы схему удовлетворить?

Ограничения - это инструмент поддержания целостности БД. Чтобы она не развалилась под руками быдлокодеров^Wпрогеров, которые всего лишь люди. Понятно, что с помощью этого инструмента можно бессмысленно усложнять жизнь другим - ну так и молотком можно забивать гвозди, а можно пробивать головы.

2) чтобы работал SQL.

Ты имеешь ввиду запросы условия вида obj.field == value? А зачем для этого жесткая схема?

Что такое «жесткая схема» - схема с драконовскими констрейнтами? Для _этого_ она не нужна (хотя оптимизатор, возможно, использует эти констрейнты). Но изначальный пойнт в том, что схема _должна быть_.

>Как раз в датамайнинге жесткие ограничения не очень нужны - данные статичны.

Только структура их весьма жосткая.

O_O

А что такое. Допусти введу я как пользователь буквы. Небо упадет на землю?

Ограничения - это инструмент поддержания целостности БД.

Целостность БД вещь весьма расплывчатая.

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

Зачем году быть цифрой?

Что такое «жесткая схема» - схема с драконовскими констрейнтами?

Схема, гарантирующая тип и наличие «field» в записи.

Но изначальный пойнт в том, что схема _должна быть_.

Я тебе приведу типичную задачу и сценарий фильма. Из SQL-реальности.

Фаза1: Есть некая сложная структура - заполнение ее инициирует пользователь. Проггер радостно делает крутые мегавизарды с лукапами и тучами проверок, результаты этого визарда заполняются в таблицы.

Фаза2: Пользователь приходит и говорит - это все клево пацаны, но то что вы не тут пятьдесятраз ругаетесь что я не заполнил обязательные поля мне жить не помогает. Я понимаю что поляя эти обязательные для структуры, но вся беда в том что я не могу их заполнить сразу. Я хочу иметь возможность заполнить немножко сегодня, отложить и заполнить немножко завтра. Тут sql-программер начинает чесать репу - пользователь хочет хранить структуры нарушающие целостность - незаполненные обязательные референсы, невведенные цифры, которые должны быть цифрами, а не пустым местом (изобретение null значенией на жесткое числовое поле было гениальным годом производителей субд). Надо или дропать все констрейнты - а это ужас, и все поля делать варчарами, или что-то придумывать. И придумывает пользователь набор новых таблиц, которые не имеют таких констрейнтов которые называет «припаркованными ордерами» и сначала в процессе действия пользователей запоняет их - а потом когда все таки заполнено - переписывает в другие дублирующие таблицы но уже с жесткими констрейнтами. Уж не говоря о том что если он пользует ОРМ - то тут вообще сума сойти какая хрень, новые наборы обектов, новый маппинг, ход конем что «lazy ref» может и не быть и т.д. На это он тратит время ресурсы индексы - их же точно так же надо находить и отображать - только данные там «неконсистентные».

Фаза3: Круто говорит пользователь, а теперь тут такая беда - для разных объектов мне надо разный набор полей. Ну ты понимаешь - у моторных лодок есть водоизмещение, а у мерседесов отсутствует характеристики хвостового двигателя. Тут уж программер вообще приходит в ужос, начинает создавать «расширенные таблицы» для каждого набора объектовб джойны за джойнами, запросы превразаются в кучи запросов, жестко чтит мануалы по «inheritance mapping to SQL», изобретает структуры данных способные это хранить. Потом пытается все это индексировать чтобы оно хоть чуть чуть шевелилось, походу начинает ненавидеть весь мир.

Фаза4: Заказчик приходит и говорит, это конечно хорошо, но это не совсем то. Я имел ввиду, что наборы свойств я буду задавать сам вводя новые типы объектов, мол сегодня торгую моторными лодками, а завтра буду подводными, и я не хочу чтобы все это переписывалось. Программер в слезах бросается читать мануалы по «mssql extended properties» перелопачивать все заново, он уже не думает о констрейнтах и структуре данных он думает каким ужасом это стало и как тяжело с этим работать их SQL, он ненавидит весь мир и думает утром об убийстве а вечером о самоубийстве, он запарился воевать со своей структурой в которую не помещаются расхлябанные данные заказчика которые он хочет раполнять как попало, проект уже превратился в говно, потому что все переписывать времени нет, заказчик не поймет и потому хаки на костылях, костылиди на хаках....

... а все от того что хотелось год писать цифрой, чтобы на это ругалась база?:)

Как история - доставляет?

>Как история - доставляет?

Доставлять-то доставляет, но никаким образом не противоречит идее о жёстких схемах. Что у моторной лодки, что у подводной есть такая характеристика, как цена. И мне было бы бы очень интересно узнать, как быстро выпнут с работы придурка, который позволит туда вводить что-нибудь типа «двацать штукарей баксафф, нах».

А у тебя схема БД описана кодом?

А что в этом странного? Я здесь не исключение. В большинстве случаев схема генерится по модели, а не наоборот.

Доставлять-то доставляет, но никаким образом не противоречит идее о жёстких схемах

Зачем базе(!) проверять пользовательский ввод? Для этого существует модель как-бы.

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

>Зачем базе(!) проверять пользовательский ввод?

Чтобы косяки разработчиков пораньше отлавливать.

>Доставлять-то доставляет, но никаким образом не противоречит идее о жёстких схемах

Серьезно?

И мне было бы бы очень интересно узнать, как быстро выпнут с работы придурка, который позволит туда вводить что-нибудь типа «двацать штукарей баксафф, нах».

Это (валидация ввода) a) никак не влияет на _схему базы_ b) не выпрут. По причине того что не надо делать допущения которых нет, и затачивать алгоритмы на крайний случай «все орзрененно правильно - иначе ничего не работает».

>оторый позволит туда вводить что-нибудь типа «двацать штукарей баксафф, нах»

Эта к стати тема нуждается в более подробном раскрытии. Подход в том что пользователь безответственный идиот имеет право на жизнь, но так же имеет право на жизнь подход «пользователь знает что делает». А писать программу которая падает от малейшего чиха в данных - вот за что руки надо отрывать. Нифатальные ошибки aka Warnings никто не отменял. Как никто не отменял и рекомендательной логики вида 'это поле таки лучше заполнить или в месячном отчете данная запись не будет учтена" вместо «а ну введи сюда число сука иначе я вообще нихрена не сохраню».

Чтобы косяки разработчиков пораньше отлавливать.

Ты, случаем, не DBA? Обычно, только они трясутся над своим ненаглядным ораклом и ходят с линейкой в программерской, а то ж обязательно насрут, эти немытые обезьяны ничего ж больше не умеют.

А если серьезно, то какой-то бред. База данных в качестве оплота корректной работы приложения.

>А если серьезно, то какой-то бред. База данных в качестве оплота корректной работы приложения.

Не оплот, а одно из средств. Всяко лучше, когда инструмент скучную работу за тебя выполняет.

>Нифатальные ошибки aka Warnings никто не отменял. Как никто не отменял и рекомендательной логики вида 'это поле таки лучше заполнить или в месячном отчете данная запись не будет учтена" вместо «а ну введи сюда число сука иначе я вообще нихрена не сохраню».

Тогда нам нужно будет выбирать, какие поля обязательны, какие желательны, а какие просто для красоты. И проверять всё это дело в нашем приложении. Т. е. делать ту самую работу, которую СУБД может сделать за нас.

> Как история - доставляет

История повествует о том, как изначальный дизайн ломается по мере развития системы и возникновения новых непредусмотренных требований. Обычное дело, схема БД тут лишь частный пример. Корежить частенько приходится всю кодовую базу, особенно если она построена на какой то «тщательно продуманной» объектной иерархии. Впрочем, я пожалуй соглашусь с мыслью, что РСУБД плохо подходит в качестве хранилища для быстроизменяющихся систем с трудно-формализуемыми данными. Домен РСУБД - это жёстко заданные структуры со сложными взаимосвязями. Поэтому 90% случаев использования РСУБД в вебе - abuse. Так что NOSQL решения я приветствую, хотя ими нынче стали частенько злоупотреблять.

> А в РСУБД я просто добавил бы индексы.

Индексы, конечно, решают проблемы, но при этом создают свои:

Отсутствие масштабируемости для очень большого количества данных. Расходование дискового пространства - иногда индексы могут занимать места больше, чем сами данные. Замедление записи на диск - ведь при обновлении записи следует обновить все индексы.

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

А если приложение имеет смешанную нагрузку - то это приводит к проблемам. Вроде и индекс добавлять плохо и без него тоже плохо.

Одним словом, как мне кажется, в области SQL баз данных разработчики прилизились к некоторому пределу, именно поэтому стали появляться попытки создания NoSQL баз данных, новые стартапы и т.д.

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

> Допусти введу я как пользователь буквы. Небо упадет на землю?

Программа упасть может. Ничего катастрофичного, если это упадет форум... но может случиться второй «Йорктаун».

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

Зачем году быть цифрой?

Чтобы тебе могли написать «r, сервер LOR поздравляет вас с 17-летием!!11».

Что такое «жесткая схема» - схема с драконовскими констрейнтами?

Схема, гарантирующая тип и наличие «field» в записи.

А как без знания о наличии поля field будет работать «SELECT * FROM t WHERE t.field == 'foo'»?

Как история - доставляет?

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

>> А у тебя схема БД описана кодом?

А что в этом странного? Я здесь не исключение. В большинстве случаев схема генерится по модели, а не наоборот.

То есть даже у тебя схема не в коде, чтд.

А то, что она генерируется по модели... прикинь, схема _всегда_ «генерировалась» по модели (в кавычках, потому что «генератором» был человек, а «моделью» - ER-диаграмма на листе бумаги).

какой-то бред. База данных в качестве оплота корректной работы приложения.

В качестве _одной из_ мер обеспечения корректной работы приложения.

> но ведь и SQL базы в начале пути тоже были не особо удобны.

Тогда у SQL (и вообще реляционных языков) было одно преимущество перед современниками - за SQL стояла четкая математическая теория. А весь NoSQL - это бунт двоечников.

> База данных без схемы данных не должна существовать.

Это точно. Без схемы плохо. Но разве это обязательно должна быть схема реляционной базы данных?

Ведь есть и другие возможности. Ведь научились же как то создавать описание XML + создали язык для его обработки. Почему бы не придумать что-нибудь похожее для NoSQL баз данных + язык для доступа к NoSQL базам данных? Конечно, если пытаться создавать приложение в виде доступа по ключам с парсингом данных, то потом приложение получится мертвым (примерно как если сразу приложение создавать на ассемблере).

> Зачем дублировать описание модели в коде и в хранилище?

Бритва Оккама? Да слышали уже. Если так рассуждать то компьютеры вовсе не нужны, так как они хранят либо отражение существующих сущностей и не нужные как лишняя копия этих самых сущностей, либо содержат какие-то свои нематериальности сущности, которые не нужны в силу их нематериальности.

>Тем, кому интересна web-разработка на Scala, предлагаю ознакомиться и поучастовать в проекте Circumflex

Кстати, ознакомился. Весьма занятная штука. Во всяком случае ORM сделан так, как сделал бы я если бы не забросил свой на фоне очередного «я хуже всех и этот велосипед никому не нужен». Может быть присоединюсь к проекту.

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

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

Или ты ответишь на вопрос почему год должен быть числом?

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

История повествует о том что широко распространена практика делать допущения каторых нет aka заказчиком не высказано, и изначально ведения дизайна программы в режиме corner case. История так же показывает стереотипный момент, когда разработчик слыша, что ему надо сохранять какие-то там «данные» тут же ставит минимум мускуль, а в совсем тяжелых случаях оракл, и вся разработка превращается в войну с инструментами и фреймворками, а не в разработку программы.

Поэтому 90% случаев использования РСУБД в вебе - abuse.

Точно.

Так что NOSQL решения я приветствую, хотя ими нынче стали частенько злоупотреблять.

Так же правильно. А то есть тенденция сначала пинать мускули куда не надо и жаловаться, а потом запихивать носкули куда надо мускули и опять же жаловаться что это плохая замена - хотя это не замена ни разу.

>Программа упасть может

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

Чтобы тебе могли написать «r, сервер LOR поздравляет вас с 17-летием!!11».

Правильно. Тут уточним - если это лоровконтакт которому эти данные нужны в качестве платы от пользователя - имеет смысл его раздражать. А если эот корпоративня система где пользователь в обще отвечает за то что вводит - зачем его раздражать и сажать в коробку от холодильника если он не просил?

А как без знания о наличии поля field будет работать «SELECT * FROM t WHERE t.field == 'foo'»?

Точто нак же как

where t.field = 21 когда там NULL. То есть фактически смысл этот такой where field_exists(t.field) and t.field = 'foo'.

Я знаю, что схема нужна, и знаю, зачем - даже килограммы самых прикольных охотничьих историй на меня не повлияют :)

А я тоже против кодда ничего не имею - он молодец. Одако имею против пионерского подхода «партия сказала 'данные' пионеры ответили 'оракл'!»

>Тогда у SQL (и вообще реляционных языков) было одно преимущество перед современниками - за SQL стояла четкая математическая теория. А весь NoSQL - это бунт двоечников.

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

Не знаю как умрающая компания новелл c акцЫями по 5.91 баксов - мне это фиолетово...

А вот в Cколково пойдет - бабла на этом поделии попилим. Таки напейшите ребе Аркаше Дворковичу

http://fintimes.km.ru/ekonomika-rossii/skolkovo/11653

http://russianews.ru/news/32625

Уже сделаем гешефт.

>Ход конем был в том что эти констрейнты никому кроме схемы не нужны. ОЧень часто вещь в себе.

констрейны типа foreign key, которые тупо рубят операцию вместо того, чтобы обеспечивать ее непротиворечивость - да. А типы данных чем повредили?

>А типы данных чем повредили?

ЗАчем год - цифра?:)

Зачастую тип данных Number говорит о том что это «обычно число». А практика говорит о том что хорошо бы это был Maybe Number. И операции связанные сним были с логикой вида «если Just Number» то обработать обычно, иначе накопить варнинг или ругнуться мрачно или скипнуть строчку или...

>я не понял зачем на быдлосайте при вводе года рождения чтоит жесткий критерий «число». Чтобы схему удовлетворить?

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

>Зачастую тип данных Number говорит о том что это «обычно число». А практика говорит о том что хорошо бы это был Maybe Number.

бывает. однако Maybe Number именно в БД очень мало отличается от просто Number, поскольку Maybe Number, это number + null, а неиспользуемых чисел обычно пруд-пруди. Для года рождения

И операции связанные сним были с логикой вида «если Just Number» то обработать обычно, иначе накопить варнинг или ругнуться мрачно или скипнуть строчку или...

две проблемы. Первая, всю эту логику приходится выносить из БД в клиента со всеми вытекающими, ибо в БД есть order by и нет «order by c варнингами». А вторая, данные, которые нельзя легко и просто использовать в логике сильно теряют свою ценность.

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

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

Или ты ответишь на вопрос почему год должен быть числом?

Зеленее дядьки тылгунира у меня ответить не получится. К тому же, незачем плодить энтропию. Поэтому я воспользуюсь его ответом.

>Как история - доставляет?

обычная история про неправильно спректированную БД.

>но так же имеет право на жизнь подход «пользователь знает что делает».

обязательно. Только обычно предполагается, что данные заполняет шестерка, а вовсе не ответственное лицо. Так что если в программе не будет проверки валидности данных, то функции проверки лягут на ответственное лицо. Думаешь, оные будут рады?

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

>>А как без знания о наличии поля field будет работать «SELECT * FROM t WHERE t.field == 'foo'»?

Точто нак же как

where t.field = 21 когда там NULL. То есть фактически смысл этот такой where field_exists(t.field) and t.field = 'foo'.

Ы? Теперь объясни мне, как без схемы работает функция field_exists.

имею против пионерского подхода «партия сказала 'данные' пионеры ответили 'оракл'!»

Ну так и не надо демагогии «зачем СУБД схема» %)

> И когда кастомные поля пытаются представить в виде таблиц или раскладывать деревянные иерархии с необходимостью вертикальных выборок в табличный вид - это значит двоечники не поняли о чем писал кодд.

Или Кодд не настолько универсальную вещь написал (см. Третий Манифест). Но все проблемы РМ не означают, что ее нужно выбросить. И уж тем более они не означают, что схема БД не нужна %)

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

Или вычислительные процессы должны учитывать что это Maybe Число.

>бывает. однако Maybe Number именно в БД очень мало отличается от просто Number, поскольку Maybe Number, это number + null, а неиспользуемых чисел обычно пруд-пруди.

Не обязательно. Это может быть чем угодно что ввел туда пользователь. НАпример «не забудь проставить сумму до 15».

Первая, всю эту логику приходится выносить из БД в клиента со всеми вытекающими,

Нет - просто бд должны уже поумнеть. Сколько можно.

ибо в БД есть order by

Он может работать аналогично сортировке чисел с нулами.

А вторая, данные, которые нельзя легко и просто использовать в логике сильно теряют свою ценность.

Эти данные - не мусор - их пишут туда осознано. Осознанно - знчит преследуюя некую цель. И использовать их в логике можно - подобная логика вот тут: http://applicative-errors-scala.googlecode.com/svn/artifacts/0.6/html/index.html

>Только обычно предполагается, что данные заполняет шестерка, а вовсе не ответственное лицо

Не предполагает. У нас как раз бизнес на подобных штуках построен. И пользователь требует то это не досполнить, то отложить на потом, то необязательность этого поля... История сверху «на основе жизненных фактов».

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

>Ы? Теперь объясни мне, как без схемы работает функция field_exists.

Когда нить видел «документно ориентированные» базы данных? База хранит именованные структуры.

>Или Кодд не настолько универсальную вещь написал

Правильно! РСУБД - нефига _не_ универсальное хранилище данных.

Но все проблемы РМ не означают, что ее нужно выбросить. И уж тем более они не означают, что схема БД не нужна %)

Никто ее не будет выбрасывать. Просто нехреново осознать что это один из инструментов и он может быть совсем не подходящим для некоторого класса задачь. И пытаться «уместить» эти задачи в этот инструмент - не всегда правильно решение. Есть еще решение - взять другой инструмент, который подходит лучше.

> База хранит именованные структуры.

То есть какая-то схема в ней всё равно есть. Потом выясниться, что эта схема одинакова у многих документов, потом - что ее хранение выгодно поручить СУБД, и со временем получится классическая архитектура со словарем данных :)

>То есть какая-то схема в ней всё равно есть.

Схема различных документов.

Потом выясниться, что эта схема одинакова у многих документов,

Что она похожа но не одинакова у многих документов - при чем типы этих документов создает пользователь.

потом - что ее хранение выгодно поручить СУБД,

И поэтому РСУБД тут подходит как свинье - седло.

>> Потом выясниться, что эта схема одинакова у многих документов,

Что она похожа но не одинакова у многих документов

Именно одинакова. Похожие схемы тоже будут, конечно.

потом - что ее хранение выгодно поручить СУБД,

И поэтому РСУБД тут подходит как свинье - седло.

Ага, я помню примерно тот же хайп насчет ООСУБД %) Впрочем, я не настаиваю именно на РСУБД, но это будет СУБД с ее обязательными атрибутами - схемой, словарем данных и прочим. И я подозреваю, что это вполне ляжет на реляционную модель.

Я понимаю корни этой вакханалии велосипедостроения... в вебдеве легионы недоучек, которым проще наклепать очередную «документно-ориентированную» поделку, чем формализовать требования и разработать новую модель данных, как когда-то сделал Кодд.

>Именно одинакова. Похожие схемы тоже будут, конечно.

Где ж одинакова если структура хранимых данных - это пользовательский ввод?

Ага, я помню примерно тот же хайп насчет ООСУБ

ООСУБД всегда был мертворожденным ребенком.

И я подозреваю, что это вполне ляжет на реляционную модель.

Как на реляционную модель ляжет отношение атрибуты которого задаются пользователем, равно как и им же определяется само отношение? Другой пользователь - другие отношения.

поделку, чем формализовать требования и разработать новую модель данных, как когда-то сделал Код

Требование простое - пользователь оппределяет структуру аттрибутов и создает сами отношения.

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

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

>> Именно одинакова. Похожие схемы тоже будут, конечно.

Где ж одинакова если структура хранимых данных - это пользовательский ввод?

Такое впечатление, что тебе не база данных нужна, а банальная ФС.

Ага, я помню примерно тот же хайп насчет ООСУБ

ООСУБД всегда был мертворожденным ребенком.

Сейчас это легко говорить.

Требование простое - пользователь оппределяет структуру аттрибутов и создает сами отношения.

Это маниловщина, а не требование.

>в вебдеве легионы недоучек,

Ага - университет вирджинии и корнуэлл полный недоучек генерящих разные Fedora Open Project и стандарты типа http://www.openarchives.org/ и прочие Dublin Core и Metadata Encoding and Transmission Standard.

>Именно в этот момент прогер с криками бросает проект и заказчика и убегает искать другого, вменяемого.

Это абсолютно нормальное требование для любой Asset Management System.

>Такое впечатление, что тебе не база данных нужна, а банальная ФС.

Лично я обычно на банальных ФС все и делаю:) Места не жрет, летает, индексируется как надо, управляется как надо.

Сейчас это легко говорить.

Тогда я так же говорил когда меня склоняли пробовать db4o 6 лет назад.

Это маниловщина, а не требование.

Тебе повторю - это нормальное требование даже для банального вебмагазина.

> Тогда я так же говорил когда меня склоняли пробовать db4o 6 лет назад.

Бгг. Я говорил об ООСУБД-хайпе рубежа 80-90-х.

Ага - университет вирджинии и корнуэлл полный недоучек генерящих разные Fedora Open Project и стандарты типа http://www.openarchives.org

Ы? Причем здесь обмен метаданными? СУБД и схемы документов - это как бэ две большие разницы.

Требование простое - пользователь оппределяет структуру аттрибутов и создает сами отношения.

Это маниловщина, а не требование.

Тебе повторю - это нормальное требование даже для банального вебмагазина.

Мы о магазинах или о СУБД?

>Ы? Причем здесь обмен метаданными? СУБД и схемы документов - это как бэ две большие разницы.

Все эти хрени надо для хранения донных. FP эо библиотечная система.

Мы о магазинах или о СУБД?

Мы о проектах в которых лепят субд для хранения данных