Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Андрей Леонидович
Чтобы не быть голословными, давайте сделаем так:
1. Вы пишите на своем языке мой "взрослый" пример, который как оказалось элементарно реализуется у Вас в инструментарии, но надо думать и в виде кода получение данного результата можно написать. У меня тоже пользователи могут в дизайнере запросов лепить запросы не зная SQL, однако все равно на сервер то скрипт уходит, так что отговорки не принимаются - скрипт в студию (и с обьяснениями по стандартной терминологии РСУБД, чтобы было всем понятно)
2. Вы на SQL переводите свой "детский" пример, чтобы мы все могли наконец понять, что же Вы хотите (лично мне что Ваш код, что поставленная формулировка задачи непонятны, но по скрипту SQL я точно пойму, чего же Вы хотите).

Далее имея 2 примера как на SQL, так и на Вашем языке мы спокойно сравниваем, выявляем достоинства и недостатки и продолжаем уже разговор опираясь на конкретные факты и примеры, а не на утверждения о неправильности SQL, необразованности молодежи, несостоятельности РСУБД, якобы молодежной терминологии, которую нормальные люди не воспринимают и т.д. и т.п. Я так понимаю у Вас здесь же нет задачи показать, что Вы самый умный, а Вы хотите поделиться с общественностью альтернативными путями решения задач и своим жизненным опытом ? Тогда ждем внятных обьяснений с примерами на SQL, что нельзя сделать на РСУБД, из за чего Вы считаете, что SQL "вреден". Жду с нетерпением, так как все время считал, что по кругу своих задач на SQL можно сделать все :)
14 июл 04, 01:52    [804668]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Андрей Леонидович
Вчера был на одном предприятии, беседовали с сотрудницей транспортно-складского хозяйства, она себе создала более 50 значительно более сложных запросов.

Вы б телефончик сотрудницы оставили, я думаю многие захотели бы ей тут работу предложить :)
14 июл 04, 09:09    [804872]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 ASCRUS

>Давайте не будем придираться, не все понимают "птичий" язык сокращений. Пусть будет так:

IF NOT EXISTS(SELECT * FROM x WHERE ...)
THEN
CALL PRG ();
RETURN;
END IF;


Это все в принципе может быть засунуто в "x", так что в "select * from x" нет сокращений, это полный скрипт, эквивалентный "i $$g(io,ie,ih)="" d ^PRG q". Хоть я и не представляю что эта абракадабра значит.

2 Andreww

>Это вы от коллеги ЧАЛ-а хотите пример получить ?

Иллюзий нет. Я развлекаюсь.

>Первое место прочно держал COBOL (!), второе и третье почти одинаково держали FORTRAN и C, С++ находился в первой восьмёрке помню точно.

Если цифры для C++ примерно равны тем, которые привел vadiminfo для РСУБД, то это говорит о том, что ОО подход по большому счету не лучше реляционного. Хоть и не окончательное доказательство, но ИМХО хороший аргумент.

2 vadiminfo

>Для данного вопроса придумывание еще одной модели кроме реляционной, уже означает, что РДМ нуждается в дополнительной, ну пусть придуманной модели. А если не нуждается, то зачем придумывать?

Двадцать раз повторил: не нуждается с необходимостью. МОЖНО придумать расширенную реляционную модель и ей концептуально моделировать, а можно и не придумывать, обойтись без концептуального проектирования.

>Если бы ER ничего не давал, им бы не занимались.

Что-то дает, но значение ER преувеличено. Например придает наукообразие проекту, начальство это любит.

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

Правильно, но в математике хотели но не могли, а в ОО могут, но не хотят. Возможно потому, что выяснится что за ОО - пустышка.

>Какие тут посылки ложные?
Пока не вижу.


Вот эта:

vadiminfo>Существенно то, что Вы подтвердили, что реляционная модель не подходит для концептуального проектирования.

Я этого не подтверждал.
14 июл 04, 10:39    [805154]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

МОЖНО придумать расширенную реляционную модель и ей концептуально моделировать, а можно и не придумывать, обойтись без концептуального проектирования.

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

Что-то дает, но значение ER преувеличено. Например придает наукообразие проекту, начальство это любит.

А придуманную скорее всего не полюбит? От того и не придумали?
автор

Возможно потому, что выяснится, что за ОО - пустышка.

Когда это выяснится, если это возможно? А что если окажется, что это не возможно?

автор

vadiminfo>Существенно то, что Вы подтвердили, что реляционная модель не подходит для концептуального проектирования.

Я этого не подтверждал

Я не предлагал использовать существующую реляционную модель для концептуального проектирования, я предлагал придумать что-нибудь на тех же принципах (множества-отображения), более подходящее, чем ER, которая не очень удачна с моей точки зрения.
Это подтверждение того, что реляционная модель подходит? Вы предолжили сосвем не много. И почему Вас не смущает, что в еще не придуманной модели формального совсем мало? Так можно доказать превосходство любой из трех: РМД, ООМД, ОРМД. Достаточно предложить придумать что-то лучшее для одной по сранению с двумя другими. Не знаю какая польза в таком доказательстве.
14 июл 04, 12:27    [805677]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Андрей Леонидович

Я признаю, что существует эпоха РСУБД. Безусловно. Но это не мешает мне считать их бесполезными.

Раз есть эпоха РСУБД , то напрашиваются термины обозначающие периоды до этой эпохи и после. Т.е. дореляционный и постреляционный периоды. Как же Вы считаете их бесполезными, если польза от них выражена в успешном продвижении инфотехнологий на предприятиях?
Андрей Леонидович

2. 25 лет назад сравнивали "объектно-ориентированные" и "записе-ориентированные" системы. Я ничего не имею против молодежной моды (терминологии). Если сейчас модно сравнивать "системы, основанные на объектах" и "системы, основанные на записях", я не против.

Дело не в моде, а в полезности терминов. Но получается, Вы сравниваете не только РСУБД, но и иерархическую и сетевую с ООМД. Как бы решаете более сложную задачу, чем указано в теме. Но в теме еще указана и ОРСУБД. Вы ее не рассматриваете совсем? Означает ли это, что ее Вы считаете вредной? Так как она пытается спасти бесполезную РМД и норовит использовать для этого подходы из ООМД? Насколько я понял Вы ярый приверженец ООМД, а с127 – РМД. А я пока склоняюсь к поддержке РМД в рамках ОРМД. Конечно, в пределах этой темы. Так как не против включения в СУБД и элементов других моделей, но с сохранением в ней РМД.
Андрей Леонидович

3. ie - это идентификатор экземпляра. $$g(io,ie,ih) возвращает значение характеристики ih экземпляра ie объекта io.
4. Насколько существенно чтение значения конкретного атрибута, конкретного кортежа конкретного отношения ? По моим данным это один из самых распространенных запросов в типичных приложениях.

Не стану Вас обманывать, но не понимаю в чем могут быть трудности у реляционной модели с чтением конкретных значений конкретных атрибутов конкретных отношений. Она в этом плане, скорее всего, не имеет конкурентов. Так как в ней это еще имеет и сильное матобоснование в виде реляционной алгебры. Или Вы имеет в виду, что она возвращает отношение, а не значение? Так в этом сила алгебры вообще и модели в частности. У нас есть отношения, которые и описываю мир. И поэтому она возвращает не только значение но и интерпретацию. Т.е. мы знаем смыл этого значения. Это особенно важно для независимости данных от программ.
14 июл 04, 13:22    [805887]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
ASCRUS !
В чем я голословен ? Ни на какой сервер никакой скрипт не уходит !
Какие отговорки ? Отговариваетесь пока только Вы.
Вам непонятен код ? Ну хорошо, я никчемный человек. Но Вы специалист в области баз данных ? Вы интересуетесь этой областью знаний ? И Вы не имеете даже представления о ЕДИНСТВЕННОМ СТАНДАРТНОМ ИНТЕГРИРОВАННОМ языке баз данных !? Нет, не нужно писать на этой абракадабре, но не иметь представления ?
ВСЕ можно сделать на РСУБД ! Если кто-то попытается в этом усомниться, не знаю как Вы, но я точно смогу его переубедить.
Я умный ? Да я как раз понимаю, что практически полный дурак, так как не знаю об окружающем мире и 1%.
Почему бесполезны РСУБД, на которых можно сделать все ? Да потому что все это не менее эффективно (мягко говоря) делается и без РСУБД.
Я понимаю что такое РСУБД. А Вы, как мне кажется, хотите разобраться что такое ООМД и ООСУБД. Я готов Вам помочь разобраться. От простого к сложному. Пожалуйста, напишите код, или уж пошлите меня куда подальше. Я же не требую от Вас кода оптимизатора. А Вы от меня требуете ВООБЩЕ НЕ СУЩЕСТВУЮЩИЙ КОД !

vadiminfo !

Я уже объяснил, что под бесполезностью я понимаю отсутствие объективной необходимости.
В моделях и терминах Вы слегка запутались. Все проще.
1. Про иерархические и сетевые модели предлагаю не вспоминать.
2. Я сразу сказал, что ООП не имеет отношения к базам данных. Программировать можно объектно, процедурно, непроцедурно, структурно. Программировать нужно хорошо. Данные должны быть отделены от программ. И т.д., и т.п. Модели данных здесь не причем.
3. Вы неточно понимаете термин КЛАСС. Перечитайте Дейта: класс в ООМД соответствует ДОМЕНУ (типу) в РМД, а не ОТНОШЕНИЮ. Про типы я вообще ничего не говорил. Отношению РМД соответствует ОБЪЕКТ в ООМД, кортежу - экземпляр (если не до конца поняли отличие идентификаторов от ключей, напишите мне - адрес Вы знаете), атрибуту - характеристика. Таким образом я сравниваю РМД и ВОТ ТАКУЮ ООМД (конечно есть еще СВЯЗЬ и характеристика связи). Классическую. Фундаментальными особенностями которой являются идентификация и навигация (а не наследование, полиморфизм, инкапсуляция, методы, сообщения).
ОРСУБД я не рассматриваю, потому что не существует ОРМД !
Я не ярый приверженец ООМД. Я с легкостью перейду в более эффективную среду разработки.
Меня очень удручает, что Вы не понимаете трудностей, которые есть у реляционной модели на простых запросах. Но давайте отвлечемся от грустных мыслей. Вы вот про Пролог упоминали. Программировал я на этом языке, и очень интересовался проблемами эффективной интеграции с реляционными БД. Но MUMPS пересилил. Ведь в MUMPS, программы, как и данные, хранятся в БД. И, как и данные, могут изменяться. То есть программа на MUMPS может изменяться в ходе выполнения. Хороший инструмент для систем искусственного интеллекта. Вот мы и начинали с диагностических (технических) эксперных систем. Но спроса на них в то время не было. Поэтому перешли на "традиционные" приложения. Но, все-таки, наибольшее впечатление (после MUMPS) на меня произвел РЕФАЛ. Но это уже другая история.
14 июл 04, 21:51    [807769]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
--То есть программа на MUMPS может изменяться в ходе выполнения.

а какие проблемы с этим у РСУБД ?

что XML документ что процедуры на java модифицироваться в результате работы сервера и изменения данных
14 июл 04, 22:34    [807813]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
ASCRUS !
В чем я голословен ? Ни на какой сервер никакой скрипт не уходит !
Какие отговорки ? Отговариваетесь пока только Вы.
Вам непонятен код ? Ну хорошо, я никчемный человек. Но Вы специалист в области баз данных ? Вы интересуетесь этой областью знаний ? И Вы не имеете даже представления о ЕДИНСТВЕННОМ СТАНДАРТНОМ ИНТЕГРИРОВАННОМ языке баз данных !? Нет, не нужно писать на этой абракадабре, но не иметь представления ?
ВСЕ можно сделать на РСУБД ! Если кто-то попытается в этом усомниться, не знаю как Вы, но я точно смогу его переубедить.
Я умный ? Да я как раз понимаю, что практически полный дурак, так как не знаю об окружающем мире и 1%.
Почему бесполезны РСУБД, на которых можно сделать все ? Да потому что все это не менее эффективно (мягко говоря) делается и без РСУБД.
Я понимаю что такое РСУБД. А Вы, как мне кажется, хотите разобраться что такое ООМД и ООСУБД. Я готов Вам помочь разобраться. От простого к сложному. Пожалуйста, напишите код, или уж пошлите меня куда подальше. Я же не требую от Вас кода оптимизатора. А Вы от меня требуете ВООБЩЕ НЕ СУЩЕСТВУЮЩИЙ КОД !

No comments - только вытекающие отсюда выводы: РСУБД и SQL Вы не знаете, красивого решения с малым кол-вом буковок на мой пример привести не можете :) От себя могу добавить из личного опыта: чтобы показать достоинства своего продукта перед другими нужно больше знать не его достоинства, а прекрасно знать из личного опыта недостатки сравниваемых продуктов. Так что Ваши уверения насчет "трудностей РСУБД на простых запросах" для меня пока выглядят честно говоря, как чистой воды ПТ, так как у меня нет понятий правильно/не правильно, я руководствуюсь принципами эффективно/не эффективно.
14 июл 04, 23:59    [807893]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 SergSuper

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

Подойдет любая бухгалтерша, работающая, например, на 1C с MSSQL сервером на бекграунде. Она только то и делает, что формирует SQL запросы, поскольку это единственный способ разговаривать с SQL сервером. Бухгалтерши об этом конечно не знают, но суть не меняется: формирование SQL запроса не такое сложное дело.

2 vadiminfo

c127>Я не предлагал использовать существующую реляционную модель для концептуального проектирования, я предлагал придумать что-нибудь на тех же принципах (множества-отображения), более подходящее, чем ER, которая не очень удачна с моей точки зрения.
vadiminfo> Это подтверждение того, что реляционная модель подходит?


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

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

>И почему Вас не смущает, что в еще не придуманной модели формального совсем мало?

Его не мало, его там совсем нет по определению. Ведь модель не придумана.

>Не знаю какая польза в таком доказательстве.

А что, было какое-то доказательство? Столио лишь сказать, что ER не нравится, как мне уже доказательство шьют.
15 июл 04, 01:10    [807916]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Андрей Леонидович

Про иерархические и сетевые модели предлагаю не вспоминать.

Согласен. Но тогда не имеет смысла вспоминать ни про модели основанные на записях, ни тем более про записеориентированные. Так как такая классификация объединяет иерархические, сетевые и реляционные в один класс моделей, а нам нужна только РМД.
Андрей Леонидович

Я сразу сказал, что ООП не имеет отношения к базам данных. Программировать можно объектно, процедурно, непроцедурно, структурно. Программировать нужно хорошо. Данные должны быть отделены от программ. И т.д., и т.п. Модели данных здесь не причем.

Вообще-то в модель данных включается и манипулирование данными, Т.е. система запросов. Это важно, потому что мы БД создаем не для того, чтобы занять персонал их набором. Иначе можно было бы создавать модели сколь угодно сложной структуры (вообще тогда бы лучшей моделью был бы реальный мир). Но имеет значение, как извлекать из них данные. По крайней мере, это относится к даталогическим моделям, т.е. ориентированным на компьютерную реализацию. И это одна из причин сложности создания даталогических моделей. Чем слабее система запросов, тем хуже для модели. Но и чем более ограничены ее структурные возможности, тем тоже хуже. Тогда в пределе вообще никаких структур модели, но максимальное программирование. Поэтому модели здесь все-таки причем. Или Вы что-то другое имели в виду?
Андрей Леонидович

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

Безусловно, я не точно понимаю термин КЛАСС. Я его пониманию на примере ООП языков как некий шаблон для определенного набора подобных объектов. Соответственно его можно считать множеством подобных объектов, а объекты экземплярами этого класса. Но если тип - это домен, то, что можно сказать об отношении – агрегации доменов? Это более сложный тип. А кортежи его экземпляры. Поэтому я и сопоставляю кортежи с объектами. Возможно, из-за неопределенности терминологии в инфотехнологиях где-то под объектом понимается шаблон экземпляров. Мне кажется, что в Паскале было что-то такое. Например, термин БД считается перегруженным: в разных источниках даются разные определения. Я читал, что в стандартах SQL намеренно не дается определение БД , поскольку разные производители истолковывают его не совсем одинаково. А Вы говорите о точном понимании.
Андрей Леонидович

ОРСУБД я не рассматриваю, потому что не существует ОРМД !

Но в каком смысле нет? Если нет общепринятой универсальной модели, то это относится и к ООМД. Однако, каждую модель данных, используемую в БД, можно отнести по каким-то признакам к тому или иному классу моделей. Мы же можем считать, что если расширить РМД возможностью включать в отношения пользовательские типы, которые поддерживают те или иные возможности объектов из ООП, то такая модель относится к классу ОРМД. Если СУБД это поддерживает, то ее можно считать плохой или хорошей, но ОРСУБД. Конечно, отсутствие общепринятой универсальной модели серьезный недостаток. Но это недостаток именно ОРСУБД. С127 из этих же соображений отрицает и ООМД. Не знаю какая в этом польза. Ведь исключается из рассмотрения целый класс моделей, претендующих на звание постреляционных. Между ними идет борьба, а мы будем думать, что их нет. В нашей стране, наверное, так отрицали кибернетику в свое время.
Андрей Леонидович

Вы не понимаете трудностей, которые есть у реляционной модели на простых запросах.

Да не понимаю. Тем более, что мне приходится париться и со сложными. От того я всегда рад простым запросам.
Андрей Леонидович

Вы вот про Пролог упоминали. Программировал я на этом языке, и очень интересовался проблемами эффективной интеграции с реляционными БД. Но MUMPS пересилил. Ведь в MUMPS, программы, как и данные, хранятся в БД. И, как и данные, могут изменяться. То есть программа на MUMPS может изменяться в ходе выполнения. Хороший инструмент для систем искусственного интеллекта.


Это уже выход за тему. Но я считаю, что ядром экспертных систем должна быть база знаний, подобно тому, как БД в ИС. И думаю, поэтому, что СУБД должна там соответствовать СУБЗ. Задачи искусственного интеллекта – задачи, которые не могут быть решены алгоритмическим способом. А вычислительные системы пока в основном алгоритмические, если не обращать внимания на нейронные сети. В общем, должны быть сделаны, наверное, какие-то заметные открытия, чтобы это все сдвинулось с места. Что такое знание Вам не скажет никто – это слишком обширное понятие. Я слышал такую классификацию: современные БД хранят фактуальные знания, так как там присутствуют связи между фактами. И соответственно современные СУБД это СУБЗ фактуальных знаний. Все проги и данные в компе – это алгоритмические знания и ОС это СУБЗ алгоритмических знаний. Но третий вид знаний – это все остальные знания. И там пока особого прорыва нет уже долгое время. Язык пролог - логический, но этого мало. Про MUMPS я никогда ничего не слышал.
с127

использование реляционной модели в концептуальном проектировании недопустимо

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

А вот если реляционную модель перенести из класса физических в класс концептуальных

Перенести никак не получится. Она прочно находится в классе датологических или по отношению к концептуальному в логических.
с127

ОО модели данных при концептуальном проектировании недопустимо.

Тут Андрей Леонидович, через записиориентированные удачно навел меня на классификацию в той книге, согласно которой ООМД наряду с инфологической ER относится к классу объектных. Т.е. как бы инфологический аспект у нее отметили уже. Т.е скорей всего может быть использована на концептуальном уровне.
Зная закон сохранения можно предположить, что плата за это кроется на логическом этапе проектирования. Наверное, трудности с построением общепринятой универсальной модели, обусловлены скорее логическим уровнем. Там и теоритическое обоснование имеет большее значение. А РМД именно на реализацию больший упор делает. Но это пока только предположения.
Но еще надо понять насколько пара ER + R проиграет OO в целом в плане проектирования. Так как ER и R достаточно притерты за четверть века усилиями многих спецов. Что мне пока совсем не ясно, так это как выглядит в этом аспекте ОРМД. Наверное, там пока на концептуальном уровне нужно смотреть в сторону UML.
15 июл 04, 02:11    [807932]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
ASCRUS ! Я с Вами, в целом, согласен. И, честно говоря, внимательно изучаю достоинства и недостатки конкурирующих продуктов. В частности буду старательнее изучать РСУБД и SQL.

vadiminfo !

1. Я готов не использовать термин записе-ориентированные (хотя РМД записе-ориентированная) ТЕПЕРЬ, когда стало понятно чем записе-ориентированные системы отличаются от объектно-ориентированных.
2. Да, способ манипулирования данными зависит от модели данных (или определяется моделью) в определенной степени (предпочтительнее отношение один-ко-многим между моделью и способами матипулирования). Но не наоборот ! Я только это хотел сказать.
3. Поскольку мы "вынуждены" сравнивать, то я говорю что "аналогом" отношения является объект (в ООМД). Но уровни абстракции разные ! Когда я говорю ОБЪЕКТ "Человек", то подразумеваю абстрактного человекА (собирательный образ человекА). А когда говорят об ОТНОШЕНИИ "Человек" подразумевают (по моему опыту ВСЕГДА) множество человекОВ. Это очень важное отличие, которое может проявляться, как ни странно, вплоть до пользовательского интерфейса. Причем, еще раз подчеркну, что на концептуальном уровне ОБЪЕКТ - это аналог ОТНОШЕНИЯ.
4. Про ОРСУБД согласен. Просто пользовательские типы и их реализация очень сложная тема (особенно, если не просто теоритезировать), и я не хотел бы еще и ее затрагивать.
15 июл 04, 19:02    [811138]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Андрей Леонидович

чем записе-ориентированные системы отличаются от объектно-ориентированных

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

предпочтительнее отношение один-ко-многим между моделью и способами матипулирования). Но не наоборот ! Я только это хотел сказать.

Не совсем понял. СУБД поддерживает несколько моделей данных, а у каждой несколько способов? Типа язык запросов SQL, QBE, поддержка непроцедурными способами. Вы про это? Уже появился термин универсальный сервер, который содержит элементы разных моделей, хотя строится на основе РМД. Или Вы все-таки про модель? Тогда поясните идею.
Андрей Леонидович

Когда я говорю ОБЪЕКТ "Человек", то подразумеваю абстрактного человекА (собирательный образ человекА). А когда говорят об ОТНОШЕНИИ "Человек" подразумевают (по моему опыту ВСЕГДА) множество человекОВ.

В прошлый раз Вы упомянули КЛАСС. Как он у вас соотносится с понятием ОБЪЕКТ? А ОТНОШЕНИЕ "Млекопитающие" разве не может содержать абстрактного человека среди прочих млекопитающих? Т.е. объектов? Т.е. в зависимости от истолкования термина Объект его можно сопоставить и кортежу. Я уже говорил Вам о неоднозначности терминов в инфотехнолгиях. Если Вы сопоставляете ОБЪЕКТ с ОТНОШЕНИЕМ, то у ОБЪЕКТА должны быть экземпляры объекта. Наверное, так термин объект понимается в каких-то источниках. В Паскле вроде бы. Но не в С++. Т.е. отношению аналогичен в этом плане скорее КЛАСС. А кортежу объект. По крайней мере, и в той книге тоже так. Т.е. Объект - экземпляр Класса. Отношение это тип (Вы сами сказали, что домен – тип, а отношение агрегат доменов – составной тип) и класс - тип. У них есть значения этих типов. У первого кортеж, у второго объект. В ER чтобы избежать путаницы между интенсионалом и экстенсионалом сущности используется термины тип сущности для первого и экземпляр сущности для второго. По умолчанию часто все-таки под сущностью понимают экземпляр сущности. Объект сопоставляется сущности. В ОРСУБД ОРАКЛ есть термин объектный тип – соответствует классу, а сами объекты принадлежат кортежам, т.е хранятся в столбцах.. А как объекты хранятся в ООСУБД? В виде каких-нибудь списков или как?
Андрей Леонидович

. Про ОРСУБД согласен. Просто пользовательские типы и их реализация очень сложная тема (особенно, если не просто теоритезировать), и я не хотел бы еще и ее затрагивать


Пользовательские типы не более сложная тема, чем классы. Кроме того, ОРМД это расширение РМД, которое и противопоставляют ООМД в постреляционный период. Поэтому если их никак не рассматривать, то картина поучится слишком урезанной. И в теме ОРСУБД упоминаетя.
15 июл 04, 23:03    [811439]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

>Я даже готов ослабить - заменить недопустимо на не совсем подходит.

Не надо ничего ослаблять. Там дальше сказано почему именно "недопустимо" и почему не надо ослаблять.

>Перенести никак не получится. Она прочно находится в классе датологических или по отношению к концептуальному в логических.

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

>Наверное, там пока на концептуальном уровне нужно смотреть в сторону UML.

Ну что такиое UML как не диаграмка, состоящая из вершин и ребер разного типа. А что такое вершины и ребра? Это граф. А что такое граф? Это бинарное отношение на множестве вершин, или в крайнем случае несколько отношений, если ребра разного типа. С ER та же история. Так что никуда за рамки реляционной модели смотреть не нужно. Все просто.

Читайте Лема, у него феномену дано объяснение.
16 июл 04, 00:37    [811545]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Не надо ничего ослаблять. Там дальше сказано почему именно "недопустимо" и почему не надо ослаблять.

Можно и не ослаблять. Хотя если БД - телефонный справочник из одной, двух таблиц, то РМД хватит и для концептуального проектирования.
c127

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

Надеюсь Вы не поместите ее в какое-то не совсем приличное место. К сожалению при отсутсвии строгости (формализации) мы не можем двигать деньги из любого банка себе в карман.

c127

Ну что такиое UML как не диаграмка, состоящая из вершин и ребер разного типа. А что такое вершины и ребра? Это граф. А что такое граф? Это бинарное отношение на множестве вершин, или в крайнем случае несколько отношений, если ребра разного типа. С ER та же история. Так что никуда за рамки реляционной модели смотреть не нужно. Все просто.

Ну что такое С как не набор функций и объявлений. А что такое функции и объявления? Это набор команд и описаний. А что такое команды и описания? Это набор машинных команд и данных на ассемблере. Так что за рамки ассеблера никуда смотреть не нужно? Можно открыть книжку по теории графов, но, скорее всего, этого будет не достаточно, чтобы построить UML диаграмку. Нужно еще быть опытным проектировщиком, которому больше платят, чем кодеровщику, который в силу институского образования, хорошо знает и теорию графов, и основы теории множеств. Кроме того, прогресс не остановить, и смотрят за рамки реляционной модели. В том числе и ее сторонники. Ведь должно же быть какое-то развитие. Или сегодняшние достижения - потолок? Впрочем, тут каждый решает сам для себя.
16 июл 04, 02:02    [811571]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

КЛАССЫ и ТИПЫ - это одно и то же. Предлагаю пока их "отложить". ОБЪЕКТ "аналог" ОТНОШЕНИЯ (отличия в абстракциях я точно изложил). Я как раз пытаюсь устранить неоднозначность терминов. А Вы мне не доверяете. Вот если бы я написал книгу, и Вы бы ее прочитали, то стали бы более-менее доверять автору книги, (но не мне ?). Я, тем не менее доверяю Вам.

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

1. Сначала нам сообщают, что в РМД связи между объектами (что за объекты !?) представляются, как и сами объекты, ОТНОШЕНИЯМИ. На следующей странице мы узнаем, что Сотрудники РАБОТАЮТ В Отделах. Протираем страницы до дыр, но так и не находим ОТНОШЕНИЯ, которое представляло бы эту очевидную связь. Но это еще цветочки.
2. Пытаясь разобраться с этой нестыковкой, приходим к выводу, что связи (теперь уже не понятно между чем) в РМД представляются с помощью КЛЮЧЕЙ. Значит ключи - это концепции СТРУКТУРЫ. Концепции структуры не должны ЗАВИСЕТЬ ОТ типов ни в каком смысле. Но тут вдруг выясняется, что внешний и, соответствующий ему, первичный ключи ДОЛЖНЫ ИМЕТЬ ОДИНАКОВЫЙ тип.
3. Крыша неудержимо едет, но мужественно продолжаем читать про реляционную алгебру и невозможность (до сих пор) ее правильной реализации (SQL)...

Именно из-за БЕЗОБРАЗНОЙ ФОРМАЛИЗАЦИИ мы, в свое время, и ВЫНУЖДЕНЫ были (скорее к сожалению, чем к счастью) разработать (точнее позаимствовать у общественного сознания) ООМД, в которой и структура, и способы манипулирования хорошо формализованы.

PS. Сочуствую, что приходится париться с запросами. Представляю какая это беда: РСУБД и SQL, ведь они основаны на плохо формализованной РМД.
16 июл 04, 13:20    [812829]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 c127 & vadiminfo, да и остальным тоже

У меня вот какие мысли по проводу ООСУБД. Мысли чисто мои, очень спорные, поэтому не обязательно они правильные, без умных слов, но думаю например c127 со мной в целом согласится.

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

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

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

Что касается неадекватности РСУБД для геодезии. Ну давайте пример в чем оно неадекватно, что по-вашему мнению будет адекватно и тогда можно будет что-то обсуждать. Аргумент что требуется очень большая модель чтоб почувствовать неадекватность - не принимается, пример всегда можно какой-то изобразить с соответствущими коментариями. Давайте хоть что-то конкретное приведём. Я вот не представляю как должна выгдяеть ООСУБД. Если Вы представляете - продемонстрируете какой-нибудь пример.

c127
Подойдет любая бухгалтерша, работающая, например, на 1C с MSSQL сервером на бекграунде. Она только то и делает, что формирует SQL запросы, поскольку это единственный способ разговаривать с SQL сервером.

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

Андрей Леонидович
Сочуствую, что приходится париться с запросами. Представляю какая это беда: РСУБД и SQL, ведь они основаны на плохо формализованной РМД.

Дык это... мы все с нетерпением ждем когда мессия нас научит работать правильно(семинар не предлагать). Пока только слова о том как мы все неправильно делаем. Теперь уже и с сочувствием
16 июл 04, 16:41    [813984]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
SergSuper !

Будьте, пожалуйста, внимательнее. Я Вам не сочуствовал. Вам я еще раз повторю: Вы все делаете правильно; в РСУБД можно сделать все; они адекватны для любых задач (без всякой иронии !). Если кто-то засомневается мы с Вами его переубедим...
Именно сама себе создала, и никаких скриптов при этом именно нет, и ни на какой сервер они именно не отсылаются.
16 июл 04, 18:06    [814371]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Андрей Леонидович

КЛАССЫ и ТИПЫ - это одно и то же. Предлагаю пока их "отложить". ОБЪЕКТ "аналог" ОТНОШЕНИЯ (отличия в абстракциях я точно изложил). Я как раз пытаюсь устранить неоднозначность терминов. А Вы мне не доверяете. Вот если бы я написал книгу, и Вы бы ее прочитали, то стали бы более-менее доверять автору книги, (но не мне ?). Я, тем не менее доверяю Вам.

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

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

1. Сначала нам сообщают, что в РМД связи между объектами (что за объекты !?) представляются, как и сами объекты, ОТНОШЕНИЯМИ. На следующей странице мы узнаем, что Сотрудники РАБОТАЮТ В Отделах. Протираем страницы до дыр, но так и не находим ОТНОШЕНИЯ, которое представляло бы эту очевидную связь. Но это еще цветочки.
2. Пытаясь разобраться с этой нестыковкой, приходим к выводу, что связи (теперь уже не понятно между чем) в РМД представляются с помощью КЛЮЧЕЙ. Значит ключи - это концепции СТРУКТУРЫ. Концепции структуры не должны ЗАВИСЕТЬ ОТ типов ни в каком смысле. Но тут вдруг выясняется, что внешний и, соответствующий ему, первичный ключи ДОЛЖНЫ ИМЕТЬ ОДИНАКОВЫЙ тип.
3. Крыша неудержимо едет, но мужественно продолжаем читать про реляционную алгебру и невозможность (до сих пор) ее правильной реализации (SQL)...

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

Именно из-за БЕЗОБРАЗНОЙ ФОРМАЛИЗАЦИИ мы, в свое время, и ВЫНУЖДЕНЫ были (скорее к сожалению, чем к счастью) разработать (точнее позаимствовать у общественного сознания) ООМД, в которой и структура, и способы манипулирования хорошо формализованы.

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

Андрей Леонидович

Сочуствую, что приходится париться с запросами. Представляю какая это беда: РСУБД и SQL, ведь они основаны на плохо формализованной РМД.

Да иногда приходится париться со сложными запросами особенно к чужому проекту. Но такой SQL запрос, написанный за несколько часов, собирает много информации в отчете, состоит из многих подзапросов. Полезна линейная алгебра для решения линейных систем уравнений? Но разве не надо париться с их решением в общем случае? А что лучше ее для этой задачи? На процедурном языке я бы склевал по полной программе для получения подобных результатов. Зато простые запросы пишутся проще чем, это предложение, что я вам пишу. Про плохо формализованную уточните все-таки. Т.е. там много содержательного, не формального осталось или что? Кроме того, за написание запросов отвечает формализация языка.
16 июл 04, 20:29    [814859]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 SergSuper
В принципе не плохая идея высказать свои представления в целом.
Я тоже тогда выскажу свои общие представления. Может это поможет нам легче понимать друг друга. Схематично они сводятся к тому, что ОО как парадигма программирования появилась с целью сокращения разрыва между реальным миром и компьютерными структурами при разработке программного обеспечения в рамках алгоритмического подхода к решению задач. А Декларативное или не процедурное происходит из стремления решать задачи искусственного интеллекта. Т.е. не поддающихся алгоритмическому способу решения. Сами компы фон Неймана могут решать только алгоритмическим способом. Поэтому эти языки это только одна из компонент решения задач искусственного интеллекта. Хотя Каспарова в шахматы обыгрывают уже, но наверное не без нейронных систем или чего-то, что можно обучать там дело обошлось. Но естественно, раз декларативные языки не требуют писать алгоритмы, то они и привлекательны. Ведь значительно проще получать результаты, когда просто описываешь что нужно, но как это реализовать в компе через алгоритмы. Но нашли они применение только в ограниченных проблемных областях, это плата за декларативнось. Однако, одной из этих областей оказались БД, которые играют огромную роль в приложениях связанных с обработкой информации. Но причиной считаю именно РМД с ее реляционной алгеброй и соответствующими ей исчислениями доменов и кортежей. Ведь это логические языки. Пролог с базами знаний работает. Но это далекие прототипы реальных баз знаний и пока прорыва нет. А будет - Пролог или его приемственник наверстает свое.

SergSuper

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

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

Что касается неадекватности РСУБД для геодезии. Ну давайте пример в чем оно неадекватно, что по-вашему мнению будет адекватно и тогда можно будет что-то обсуждать. Аргумент что требуется очень большая модель чтоб почувствовать неадекватность - не принимается, пример всегда можно какой-то изобразить с соответствущими коментариями. Давайте хоть что-то конкретное приведём. Я вот не представляю как должна выгдяеть ООСУБД. Если Вы представляете - продемонстрируете какой-нибудь пример.

Можно вернуться и к примерам, и к недостаткам. Однако, надо как-то более системно подойти. Иначе создается впечатление, что пример только один и недостаток только один. И создается иллюзия, что стоит только найти ухищрения или доказать, что это не недостаток, то все проблемы сняты. Причем не всегда ясно, почему это доказательство - действительно является таковым.
Кроме того, мы и термины понимаем по разному – надо их согласовать.. Например, я уже не понял, что имеется в виду под большой моделью. Как-то обозначать промежуточные результаты, чтобы избежать бесконечных кругов. Вязнем на деталях, которые являются малозначимыми по отношению к теме.
Мы можем и менее тривиально подойти. Мы реляционщики и должны уметь придумать сами что-то солжное для реализации в РСУБД. Примеры то я брал из книги. Что касается ООСУБД, то тут надежды на Андрея Леонидовича. С которым мы пока не определимся никак в базовых терминах. Я могу больше в плане ОРСУБД, хотя в думаю что их реализация объектных типов носит пока больше исследовательский характер в целом. Но можно, например, посмотреть, что ОРАКЛ сам навоял для XML или геометрических задач. Уже ясно, что эти задачи он не посчитал реляционными. Т.е. он склепал там уже типы, методы.
16 июл 04, 22:55    [815052]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
SergSuper

Есть одно возражение.

>Когда собственно обычное процедурное программирование стало развиваться дальше реально оказалось два пути: ОО программирование и декларативное програмирование.

Альтернативой декларативному (аппликативному) программированию есть императивное программирование, ОО программирование попадает в более "мелкую" классификацию: функциональное (лисп), логическое (пролог), процедурное (C, фортран), ОО (smalltalk и C++ под вопросом). Первые 3 аппликативные, последние 2 - императивные. Вроде ничего не напутал.

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

С остальным согласен.

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


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

2 vadiminfo
>Так что за рамки ассеблера никуда смотреть не нужно?

В принципе - да, можно и не смотреть. Даже есть такая теорема. Но на деле от ассемблера до баз данных шагать и шагать, а от UML схемы до реляционной модели в которой UML может быть записан - один шаг. Поймите, я не против UML, я против того, что пошла мода не формализовать даже такие легко формализуемые, по-моему, вещи как UML. Это вдруг стало считаться нормальным.

>Хотя Каспарова в шахматы обыгрывают уже, но наверное не без нейронных систем или чего-то, что можно обучать там дело обошлось.

Нет там никаких нейронных сетей. Есть хитрый перебор, совершенно классический. Постараюсь найти ссылку.

>Но можно, например, посмотреть, что ОРАКЛ сам навоял для XML или геометрических задач. Уже ясно, что эти задачи он не посчитал реляционными.

Вы все время забываете о влиянии рынка. Модно сейчас XML - вот вам, только платите деньги. А нужно оно или нет - это не важно. У них производителя одна проблема: чтоб эти модные нововведения не сломали ту часть, реляционную, которая надежно работает и которая в основном и используется. XML вообще без проблем записывается в реляционной модели. Дерево оно и есть дерево.
17 июл 04, 04:07    [815234]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
Здесь много говорилось о РБД и ООБД в том числе с точки зрения концептуального проектирования. Хочу добавить пару реплик:

1) Если у человека нет порядка в голове, то ничего хорошего он не спроектирует, какой бы инструмент ему в руки не дали.

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

3) Представьте двух человек которым поставлена задача свалить дерево. Одному рядом поставили топор, другому - бензопилу. Первый начинает планировать как он будет обходить с топором дерево и когда ему сделать перерыв на обед (потому что до обеда он дерево срубить не успеет), а второй планирует как он запустит пилу, быстренько спилит дерево и куда быстро отскочить что бы дерево не зашибло. В обоих случаях дерево будет свалено. Я это к тому что используемый инструментарий НАВЯЗЫВАЕТ способы решения задачи. А значит со временем у разработчика могут сформироваться стереотипы и фиксации в его СПОСОБЕ МЫШЛЕНИЯ. Я не хочу сказать что топор - это РБД или ООБД. Если перед человеком положить и топор и бензопилу, но он не знает как пользоваться бензопилой, он выберет топор. Девиации в мозгах могут зайти настолько далеко что человек превращается из материалиста в идеалиста и искренне считает, что строка в какой нибудь таблице и есть экземпляр объекта, в то время как это всего лишь одна из форм представления ОПИСАНИЯ ОБЪЕКТА. Понятно что наверное есть задачи более подходящие для решения тем или иным способом, но что бы воспользоваться ООБД для решения какой нибудь задачи большинству БД программистов придется серьезно ломать свой стиль мышления.

4) А есть ли ради чего ломать? Наверное это основной вопрос. Пока не видно ни единого подхода к технологии ООБД, ни единственного вполне удачного и удобного. Причем много усилий в этой области направлено на потребу ООП программистов. И многие искренне уверены, что ООБД должна слепо реализовывать три великих принципа ООП, хотя это совсем не так.
17 июл 04, 20:44    [815649]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Давайте я скажу об объектах в рамках классической ООМД, а Вы сами решите как ОБЪЕКТ соотносится с КЛАССОМ и ОТНОШЕНИЕМ.

Объект всегда в единственном числе.
Он может быть либо абстрактным - абстрактный Человек,
либо конкретным - конкретный Человек.
Прилагательные "абстрактный" и "конкретный" для упрощения не используют (что, конечно, затрудняет понимание):
- абстрактый объект в ООМД - это ОБЪЕКТ;
- конкретный объект в ООМД - это ЭКЗЕМПЛЯР.
Когда говорят "экземпляр объекта" ("опасное" для понимания словосочетание), подразумевают, конечно, экземпляр абстрактного объекта, а не элемент какого-то множества.

Множество ОБЪЕКТОВ - это то же самое, что и множество ОТНОШЕНИЙ.
Конечно экземпляров тоже много. Множество есть. Следовательно, способы манипулирования, основанные на операциях над множествами, могут использоваться в ООМД. Но я думаю не следует говорить о "реляционной надстройке" в ООМД. Интеграция должна быть органичной, и модель останется ОО, и СУБД останется ОО. Важно, что обратное невозможно: в РМД нельзя реализовать "ручную" навигацию.

Ключи - это концепции структуры. Вы их используете для представления связи "Работает в" между "Сотрудником" и "Отделом". Зачем скрывать этот факт за фразой "связь ... реализуется с помощью миграции атрибутов" ?
18 июл 04, 00:48    [815758]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
serg99 !

Мне понравился Ваш пример с топором и бензопилой. Инструментарий действительно навязывает способы решения задачи. И стереотипы действительно формируются. Но фраза про девиацию в мозгах закончена неудачным сравнением. Если в РМД (?) строка таблицы - это форма представления описания объекта (?), то в ООМД строка таблицы - это форма представления экземпляра.
18 июл 04, 01:14    [815770]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
vadiminfo !

Структурный аспект формализован безобоазно в РМД. Это не поспешный вывод, сделанный, правда, очень давно. Но с тех пор в РМД ничего не изменилось. У меня нет никаких новых данных, чтобы этот вывод изменить. А Вы все время говорите о хорошей формализации аспекта манипулирования. Я считаю аспект манипулирования второстепенным. Вы, видимо, считаете аспект структуры второстепенным.
18 июл 04, 01:28    [815776]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
Андрей Леонидович
serg99 !

Мне понравился Ваш пример с топором и бензопилой. Инструментарий действительно навязывает способы решения задачи. И стереотипы действительно формируются. Но фраза про девиацию в мозгах закончена неудачным сравнением. Если в РМД (?) строка таблицы - это форма представления описания объекта (?), то в ООМД строка таблицы - это форма представления экземпляра.


Я использовал терминологию принятую в ООП. Там, то что Вы называете Объектом называется Классом. При этом Объект и Экземпляр являются в общем то синонимами. "Экземпляр Объекта" - это конечно тавтология призванная всего лишь подчеркнуть что речь идет о наборе атрибутов описывающих один конкретный объект "реального мира".
18 июл 04, 02:11    [815809]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить