MasterZiv
Бредятина wrote:

> Ну, если уж точно, то 35:) System R

Да нет, ровно 40. Манифест в 1970 году вышел.

В своем первом сообщении на эту "подтему" Вы говорили о "появлении первых СУБД", не так ли? Некоммерческая по сути System R появилась в 1975 году (я же Вам дал ссылку на рассказ очевидца:)). Теперь Вы заговорили о статье Кодда 1970 года, почему-то назвав ее Манифестом. Первые, очень важные, ксатати говоря, для понимания неразрешимых проблем РСУБД, работы Кодда (техническин отчеты IBM) появились, естественно, еще раньше. Так что сорока нет ни в одном, ни в другом случае:). Но лучше я с Вами соглашусь. 40 так 40. Это все равно один миг:)

Bogdanov AndreyБредятинаПользователь безусловно может добавлять характеристики объектов, а также и сами объекты и связи между ними в работающем приложении (без участия программистов-разработчиков). Это давно делается на практике, успешно работает, и чрезвычайно полезно:)
Это действительно делается уже давно, практически во всех РСУБД и успешно работает.
Это, конечно же не делается ни в одной РСУБД, и практически наверняка, никогда не будет делаться.

egorychБредятина:
>> А с Вами мы же решили "свой" вопрос - нет никаких СУБД, кроме "реляционных":)
мне постоянно кажется, что у Вас есть другой ответ на этот вопрос, но, право, мне никак не удаётся его узнать. Неужели это самая страшная тайна? ;-))
Я честно не знаю как ответить на утверждение, что нет никаких СУБД, кроме РСУБД. Хорошо известно, что в природе не существует ни одной реляционной СУБД. Просто никому не удалось создать такую СУБД. Так что наиболее напрашивающийся ответ - нет, пока, вообще никаких СУБД:)

egorychБредятинаЯ честно не знаю как ответить на утверждение, что нет никаких СУБД, кроме РСУБД. Хорошо известно, что в природе не существует ни одной реляционной СУБД. Просто никому не удалось создать такую СУБД.с теоретической точки зрения, Вы, несомненно, правы. С практической же - есть таки несколько СУБД, которые себя позиционируют как "реляционные", довольно успешно существующие в объективной реальности. Значительно большие проблемы с успешностью наблюдаются с СУБД, которые позиционируют себя как "нереляционные".

>> Так что наиболее напрашивающийся ответ - нет, пока, вообще никаких СУБД:)
и кто, или что, управляет базами данных, в таком случае, по Вашему?

А зачем нам с Вами разбираться с проблемами "позиционирования"? Я могу только по существу что-то обсуждать. А по существу (а не теоретически) нет никаких реляционных СУБД.
IS, например, позиционирует Cache, как "постреляционную", звучит странно, учитывая, что "реляционных" никогда и не было. И т.п. Так что с "позиционированием" не стоит разбираться... А базами данных управляют люди с помощью программ. А эти программы производители ПОЗИЦИОНИРУЮТ как "системы управления базами данных". А с "позиционированием", как я уже сказал, лучше не связываться:)
Так что у реальных СУБД все еще впереди.

egorych
таким образом, подводим черту под нашим с Вами "вопросом": реальных реляционных СУБД нет, следовательно, и других СУБД тоже нет. Однако есть некие программы, которые принято в простонародье называть термином "реляционные СУБД", или, для краткости - "РСУБД". Действительно, обсуждать далее этот вопрос становится неинтересным, тут я с Вами совершенно согласен.
Мне, как человеку, управляющему этими пресловутыми "РСУБД", и, в меру сил, разрабатывающему свои маленькие велосипеды на их основе, интересно Ваше мнение вот по какому поводу: какую пользу мне, и пользователям моих поделий ( о них не забываем, конечно, никогда ) может принести доведение "РСУБД" до уровня реальных реляционных СУБД ( или сразу перешагиваем дальше? ), как Вам видится? Я почему спрашиваю: никак не могу понять Вашу позицию, с одной стороны существующие "РСУБД" Вас явно не устраивают, но что нам делать дальше в связи с этим, куда, так сказать, двигаться, не понимаю.
Ну, если конечно, Вас это не сильно затруднит, и, если, топикстартер простит нас за оффтоп, естественно ))
Меня не затруднит, и это не такой уж и оффтоп (автор темы работает частично и в этом направлении).
Про пользу от доведения можно посмотреть у Дейта. Мое мнение известно: бесполезно:) Слишком много недостатков у РМД. Здесь они подробно обсуждались (в том числе и в этой теме). Только не перешагиваем, а, скорее, возвращаемся к классической объектной модели данных. Она была частично и весьма скромно реализована в "дореляционных" объектно-ориентированных системах (которые обычно называли "сетевыми" и "иерархическими"; в отличие от них "реляционные" системы являются записеориентированными). Фундаментальными и непреодолимыми недостатками РМД являются: отсутствие идентификации объектов, и, соответсвенно, (симметричная проблема) отсутствие связей между объектами. Из этого уже вытекает отсутствие метаданных (то, что мы здесь частично обсуждаем) и др.

ViPRos
Во надстройка над РСУБД. Все путем.
Не смешите:) Напомню, что речь идет о РСУБД, а не о приложениях. Реализующих не известно какую еще одну модель данных, к тому же...

ViPRosБредятина_модБредятинаЯ Вам и объяснял много раз, что РСУБД никакие не СУБД:)
Да какая разница как назвать, все равно никакая СУБД не позволяет конечному пользователю менять структуру БД.
Зачем же Вы добавляете новые прилагательные:) Прилагательные вообще нежелательно использовать при обсуждении существа вопроса. "Конечный"... А "промежуточный"? Или "полусредний"?



После вышесказанного это выглядить нехорошо.:)

БредятинаНапомню, что я использую пару терминов объект/экземпляр, а не класс/объект.. Чтобы не было недопонимания предыдущего сообщения

Финальность типа вычислима в любом контексте, а без контекста приудительная декларация финальности ущербна.
Вы о чем, если не секрет?:)

vadiminfoegorychсуществующие "РСУБД" Вас явно не устраивают, но что нам делать дальше в связи с этим, куда, так сказать, двигаться, не понимаю.

Ну это предельно просто: уйти с РСУБД на ИнформХ типа ОСУБД. На, самом деле, на Каше налабанная тулса, выдаваемая ранее за СУБД, балабановским со спичечной фабрике впендюренная лет 15 назад.
Рассуждение таково: Раз нет РСУБД, то на безрыбьи и ИнформХ сгодится. Ну типа он лет 30 назад не угадал с выбором (выбрал Мумпс вместо РСУБД), и до сих пор ждет (на Кашу перебрался), что тренд изменится в его сторону. Расчет делается на достаточно отсталые в плане технологий БД группы населения, чтобы им можно было впендюривать второсортные поделия.
Так что что тем кто его послушает делать дальше более или менее ясно.
А вот и местные "специалисты" по СУБД ожили:) С какими-то спичечными фабриками и информиксами:) Эти ребята по существу ничего не способны обсудить, из-за проблем с преподавателями (как ранее выяснилось):) Cache лучше Оraclе только лишь благодаря технологии, но не благодаря реализации собственно СУБД. Однако это уже пройденный этап, хотя и очень успешный, так как и СУБД и крупное приложение функционируют успешно в течение 15 лет, причем вовсе не на Cache:) Вы, дорогой vadiminfo, угомонились бы уже:) Вы занимаетесь правильной технологией и правильным образом. И все у Вас хорошо. Что же Вы переживаете?:)

_модБредятинаПользователь безусловно может добавлять характеристики объектов, а также и сами объекты и связи между ними в работающем приложении (без участия программистов-разработчиков). Это давно делается на практике, успешно работает, и чрезвычайно полезно:)
Для того, что-бы КОНЕЧНЫЙ пользователь мог менять стуктуру БД, он должен ее знать, что по определению конечного пользователя невозможно, т.к. информационная модель строится разработчиком, т.е. другим человеком.
Вы очень серьезно заблуждаетесь, видимо, находясь в плену реляционной технологии. Других причин я не вижу.

egorychБредятина, связи между объектами, неужели Вы считаете, что они так уж необходимы именно в базе данных? Обладая "реляционными" данными ( или, скажем по другому: фактами ) я могу создать любые нужные мне в текущий момент логические связи между ними, смогу ли я с такой же лёгкостью вертеть "объектные" данные с жёстко прописанными связями и ссылками друг на друга? Как мне кажется, место связям, да и объектам как раз в приложениях, обрабатывающих эти факты.
ну и если вернуться с теоретических высот к презренному железу, то, кмк, фундаментальным недостатком объектно-ориентированных систем управления данными является производительность. Скорость, с которой обрабатывает массив данных движок современной "РСУБД", пока ещё даже не снилась существующим объектно-ориентированным системам... или уже снилась?
Все, о чем вы говорите подробно обсуждалось на семинарах 25 лет назад. Я не просто считаю, я хорошо это знаю и понимаю. Потому что все это прошел на практике, и могу сравнивать реализацию именно связей (в РМД нет никаких связей в принципе, хотя Кодд и пытался их ввести в РМД, но не получилось) и важность их использования (что совершенно не отрицает возможность, значительно менее востребованную, связей по "характеристикам объектов") с возможностью "создать любые нужные мне в текущий момент логические связи между реляционными данными" (то есть, "связывание" только по характеристикам объектов). Сказать, что возможности РМД существенно беднее, это ничего не сказать:)

mcureenabegorych,

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


Реляционные модели уже давно строят только студенты на лабах, а в промышленных системах используют ER и сурогатные ключи, которые по сути олицетворяют собой платформно-независимые указатели или Object ID.
1) Именно "приспособить":) Так же, как, например, к автомобилю вполне можно приспособить пропеллер.
2) Объектные ссылки - это не связи (которые есть на уровне ER). А ключи, пусть и суррогатные, - это не идентификаторы, а просто те же атрибуты отношения. Идентификатор - это принципиально не характеристика объекта.

_модБредятинаДругих причин я не вижу.
Это-то и плохо
Ну это уж точно Ваша проблема - в чем именно кроется причина Вашего заблуждения:)