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

Откуда:
Сообщений: 729
Дым коромыслом опять. И новое определение навигации от Андрея Леонидовича
2 авг 05, 01:06    [1753905]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Андрей Леонидович
И про навигацию, и про многие ее аспекты подробно говорил, но Вы ничего не хотите слушать, а только опять задаете какие-то банальные вопросы...
Ссылки в студию на посты с рассуждениями по этой теме, покрывающие указанные мной вопросы. И особенно — ссылку на ваше определение навигации, если утверждаете, что оно было. Только не надо тот мусор, на который я подробно отвечал в постах 1 и 2. Каждый может судить, насколько «формальное» Андрей Леонидович давал определение:
Андрей Леонидович
Когда пользователь нажимает клавишу <стрелка вниз> или <стрелка вверх>, и "перемещается" на следующую (предыдущую) запись товарной накладной - это навигация.
IMHO, строгость постановки на уровне «первый класс, вторая четверть».
Ну а теперь посмотрим дальше:
Андрей Леонидович
(1) навигация - операции перебора (и для программиста, и для пользователя) и извлечения данных экземпляров: а) внутри объекта, б) внутри связи (был так же отдельный разговор про индексы - что это полноценная часть данных, в отличие от РМД и "Р"СУБД);
То есть термин «навигация» по-вашему завязан строго на понятия:
• программиста,
• пользователя
• экземпляров (неизвестно чего)
• объекта (а это что за зверь? Неужто то, что «противоречит субъекту в его предметно-практической деятельности» ((c) by ЧАЛ). Вот умора!)
• связи (опять же, чего-то с чем-то, видимо, надо додумывать).
Да еще и индексы приплетены. Значит у вас логическая концепция «навигации» не существует без физической концепции индексов. То есть вы не в состоянии отделить логический и физический уровень манипуляции данными.
Да-а-а. Строгость «на высоте». «Определение» требует еще минимум 3 доопределения. Попытка не засчитана.
Андрей Леонидович
(2) всегда доступна;
Это о чем? Обрывок мысли?
Андрей Леонидович
и ПОДРОБНО ОБЪЯСНЯЛ о нужности со статистикой примеров (извлечь определенные характеристики конкретного экземпляра; извлечь все "записи" (в широком смысле) конкретного "документа" (в широком смысле) и т.п.) для типичных OLTP-систем;
Ссылки, цитаты? А то, как говорится, п#@$ть — не мешки ворочать.
Андрей Леонидович
(3) навигации нет в РМД по определению (см. свойства отношения);
Доказательства?
Андрей Леонидович
(4) курсоры в SQL-СУБД - это навигация;
Как интересно! Ну-ка все вспомнили, что навигация по «определению» выше завязана на понятия неких «экземпляров неизвестно чего», «объектов» и «связей». Ничего такого в SQL-СУБД нет. А вот навигация, как утверждается — есть. Какую траву вы курите?
Андрей Леонидович
и они именно категорически противоречат РМД; их НЕ МОЖЕТ БЫТЬ В РСУБД
Доказательства?

Увы, как и ожидалось, ничего доказательного вы произвести не смогли. Видите ли, ваши утверждения сами по себе доказательствами ни для кого не являются, вот беда-то. Пора бы перестать утверждать и начать доказывать.
2 авг 05, 10:57    [1754547]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
Андрей Леонидович
Guest
Обратите внимание, что это даже не столько я (хотя, конечно, тоже постарался), сколько ваша собственная тупая ненависть к новым знаниям, поставила вас, mir и vadiminfo, в тупик. То есть поняли, что я вам долбил полтора года (навигация нужна почти всем приложениям, а в РМД ее нет по определению), и теперь не знаете, что с этим делать, кроме как реализовывать навигацию в постреляционных "Р"СУБД, и во всевозможных надстройках...

Молодец, vadiminfo ! Читаете новую толстую книгу. Но упорно хотите выглядеть дураком. Приходится опять читать вместе с Вами, как с ребенком:

"Оператор ORDER BY не является реляционным оператором, поскольку возвращаемый им результат не представляет собой отношение."

Ну что, еще и свойства отношения только под моим руководством сможете изучить ? Не прикидывайтесь дураком, vadiminfo - это Вас не красит...

Как и Вас, mir. Из того бреда, что Вы написали, можно сделать только один вывод: Вам срочно нужно получить дополнительное образование по РМД. И я готов Вам помочь. Для начала:

1) изучите свойства отношения РМД, чтобы больше не позориться;
2) ведите себя прилично; внимательно изучите мои ответы на Ваши вопросы, и, если чего-то не поняли (это часто случается при изучении новых тем), то вежливо переспросите (особое внимание обратите на последние абзацы):

"Думаю, что бесполезно с Вами говорить про навигацию. Вот закончим с идентификацией (с ролью ключей и кортежей в РМД), где ИМЕННО ВДУМЧИВО, С ЦИТАТАМИ И ССЫЛКАМИ я уже полтора года доказываю очевидные вещи, а в ответ только ругань и демагогия.
И про навигацию, и про многие ее аспекты подробно говорил, но Вы ничего не хотите слушать, а только опять задаете какие-то банальные вопросы...

(1) навигация - операции перебора (и для программиста, и для пользователя) и извлечения данных экземпляров: а) внутри объекта, б) внутри связи (был так же отдельный разговор про индексы - что это полноценная часть данных, в отличие от РМД и "Р"СУБД);

(2) всегда доступна; и ПОДРОБНО ОБЪЯСНЯЛ о нужности со статистикой примеров (извлечь определенные характеристики конкретного экземпляра; извлечь все "записи" (в широком смысле) конкретного "документа" (в широком смысле) и т.п.) для типичных OLTP-систем;

(3) навигации нет в РМД по определению (см. свойства отношения); что еще за "прошу заметить" ???

(4) курсоры в SQL-СУБД - это навигация; и они именно категорически противоречат РМД; их НЕ МОЖЕТ БЫТЬ В РСУБД, но они, конечно же, могут быть (точнее, должны быть) в "Р"СУБД (постреляционных СУБД)...

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

P.S. mir (18 фев 05, 06:33):

"Более того, в РСУБД практически любое решение на основе курсора можно преобразовать в эквивалентное без курсора. Ваше мнение: прав ли я ? (Прошу коллегу ЧАЛ не влазить в диалог)."

Если уже можно влазить", то Вы не правы. В РСУБД, когда они будут созданы, не может быть "решений на основе курсора", по определению...

И не пишите, хотя бы, совсем откровенных глупостей, типа "противоречит субъекту"...
3 авг 05, 00:13    [1757910]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
vadiminfo
Member

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

(навигация нужна почти всем приложениям, а в РМД ее нет по определению),

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


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

"Оператор ORDER BY не является реляционным оператором, поскольку возвращаемый им результат не представляет собой отношение."

А SQL применяется не к отношениям, а к их представлениям - таблам (реляционным). И потому естественно реляциолнная часть может быть дополнена средствами работы с таблами. Таблы то так или иначе упорядочены. Просто они считаются равными, если отличаются тока порядком.

Ну что? Съели? Не выкинем ORDER BY, и не уговаривайте в надежде сократитть отстование Вашей дореляционки.

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

Ну что, еще и свойства отношения только под моим руководством сможете изучить ?

А может под Вашим руководством поизучать и теорию групп, модули и кольца, теорию решеток или общую топологию? Что ж на каких-то там отношениях останавливаться? Хотя, возможно, для Вас это потолок. Математика у Вас хромала? Я прав? Хотя бы помните что такое нильпотентная группа? Или Нетеров модуль? Что Вы там закончили? Как назывался тот техникум? Я забыл. Иначе зачем мне такое руководство как Ваше в изучении теории множеств, если Ваши профессора были хуже моих? И в математике Вы не рюхаете совсем.


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

внимательно изучите мои ответы на Ваши вопросы

Вообще-то Вы больше прославились тем, что не отвечали на вопросы. Кроме того, на что Вы можете ответить, если не понимаете что Вам говорят? Разговор с Вами как с глухим. Вы тока повторяете одно и то же, не обращая внимания или не понимая, что оно давно опровергнуто. Кто Вас знает. У Вас ведь голова не тока для того, чтобы есть? Хоть немного внимательней читайте что Вам пишут. Вот всякий вздор повторили два раза. Ниче не поняли что Вам сказали.
3 авг 05, 01:47    [1757944]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
mir
Member

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

Как, собственно, и ожидалось, по теме разговора ни одной ссылки, аргумента, доказательства вы так и не привели. Все время переводите разговор из более-менее научной плоскости в эмоционально-болтологическую. Я спрашиваю "Где ссылки?", а вы мне «ваша собственная тупая ненависть к новым знаниям, поставила вас в тупик». Я спрашиваю «Где доказательства?», а вы мне «Вам срочно нужно получить дополнительное образование по РМД». Я вам «обоснуйте», а вы мне «внимательно изучите мои ответы на Ваши вопросы». Родной мой человек, так ведь в том-то и беда, что не было никаких «ответов». И не было у вас никаких аргументов. И не было никаких цитат. И не было никаких ссылок. Только голые заявления.
И, разумеется, вы опять демонстрируете умение делать Copy-Paste. Зачем? Зачем повторять этот пост, если я его только что разобрал, задал конкретные вопросы и высказал конкретные замечания. Вот на них и отвечайте. Если сможете. А копировать исходный пост, не отвечая на претензии, легко.
Однако это лучше и красноречивей всего говорит о вашей беспомощности в формальной аргументации.

Итак, попробуйте для начала еще разок дать свое определение навигации. С учетом моих вопросов и замечаний . То есть вполне строгое и по возможности самодостаточное. Ваше, как я указал, таковым не является. Поскольку ссылается еще на 5 (!) понятий, 3 из которых требуется определить:
• экземпляр (неизвестно чего)
• объект
• связь (чего-то с чем-то)
Соответственно, еще и неясно, что значит «внутри объекта» и «внутри связи».

Вы ж у нас мега-теоретик. Опровергатель авторитетов мирового масштаба. Так сказать, живая скульптура «Андрей Леонидович, разрывающий пасть Кодду». Так попробуйте хотя бы формально определить то, о чем беретесь рассуждать.

P.S. Насчет «противоречит субъекту» моя вина, правильно «противоречит субъекту». Да слаще ли хрен редьки?
3 авг 05, 10:16    [1758362]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Черт, "противостоит субъекту", конечно.
3 авг 05, 10:19    [1758376]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
Андрей Леонидович
Guest
Так что, mir и vadiminfo, мы уже закончили с "ролью ключей в РМД" ?
И вы со мной согласились ?
И можно переходить от идентификации к навигации ?

P.S. Или может, проведем семинар по РМД (ведь она "хорошо формализована"), где вы не сможете вилять и врать, как здесь, и опубликуем здесь его результаты ?
А, если захотите, проведем семинар и по ОМД, если вы, действительно, даже эту прекрасно формализованную модель не понимаете...
3 авг 05, 22:01    [1761795]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
c127
Guest
vadiminfo

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

"Оператор ORDER BY не является реляционным оператором, поскольку возвращаемый им результат не представляет собой отношение."

А SQL применяется не к отношениям, а к их представлениям - таблам (реляционным). И потому естественно реляциолнная часть может быть дополнена средствами работы с таблами. Таблы то так или иначе упорядочены. Просто они считаются равными, если отличаются тока порядком.

Ну что? Съели? Не выкинем ORDER BY, и не уговаривайте в надежде сократитть отстование Вашей дореляционки.


Говорил уже, ORDER BY можно выкинуть, навигация (которая все еще не определена несмотря на все обещания) замечательно организовывается и без него, если очень хочется, это лишь вопрос удобства.

Проблема в том действительно ли навигация является такой необходимой, как хотелось бы Андрею Леонидовичу. По-моему совсем не необходима, более того, я даже не очень педставляю куда ее в прикрутить на стороне сервера. А если принять за определение знаменитое "<стрелка вниз> - <стрелка вверх>", то навигация в СУБД совершенно, как бы это сказать, бесполезна по причине отсутсвия стрелок.
3 авг 05, 22:09    [1761804]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
Андрей Леонидович
Guest
Не говорите глупостей, с127. В РМД, а, следовательно, и в Р(без кавычек)СУБД навигации нет, по определению. А она нужна практически для любого приложения. И именно СУБД, а не само приложение, должна ее поддерживать...
Пошли по пятому кругу. Вы не понимаете не только что такое интегрированный язык баз данных, но и "симметричную задачу" интеграции навигационных свойств СУБД и навигационных потребностей приложений. Вы даже не знаете, что в СУБД есть не только "знаменитые" <стрелки вниз и вверх>, но и не менее "знаменитые" <стрелки влево и вправо>. Докатились...
3 авг 05, 22:44    [1761850]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
vadiminfo
Member

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

ORDER BY можно выкинуть

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

c127

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

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

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

Но в некоторых случаях навигационный имеет преимущества.
1. Про рекурсивныем мы с Вами когда-то говорили. Однако, их стараются включить в SQL. В Скуле и DB2 - есть рекурсивные запросы, насколько я понял на форуме.
В Оракле есть иерархические запросы - для транзитивного замыкания. Он его совершенствует вроде по мере новых версий.
2. interrow вычисления. Я говорил, что Оракл налабал средства и для такого типа задач в 10 версии. Правда, пока не пробовал. Не поставил еще 10. Хотя, в общем, случае вычисления - это уже дополнительное по отношению к главной задаче - извлечение информации из БД. Но тем ни менее в некоторых случаях это может рассматирваться как запрос. Тут не всегда просто провести границу.
3. Ну собсно задачи, где РМД не совсем адекватна и имеет место, например, лавинообразное увеличение количества деталей. Иногда говорят, что в этом случае навигация может быть предпочтительнее.

4. Вопрос о преимуществе доступа по адресам (навигация) в плане производительности в некоторых случаях - может иметь преимущество.
Надо тока иметь в виду, что на физическом уровне в РСУБД используется так называемая автоматическая навигация - конкретно извлекает блоки, например, по адресам. Поэтому тут разница не всегда очевидна. Да и вообще вопросы производительности не всегда связаны, скорее всего, с моделью данных.

Т.е. не факт что SQL в своем развитии не порешает многие из тех задач где навигация была предпочтительней. Реляционность самого извлечения остается как основополагающее - выборка, проекция и проч алгебраические операции. А дополнительные вычислительные возможности в SQL никто не запрещал. Наоборот. Поощрял.
3 авг 05, 23:35    [1761897]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
c127
Guest
vadiminfo

Нет, выкидывать не стоит.


Я согласен с тем, то выбрасывать ORDER BY не нужно, но в принципе это сделать можно. Я это и говорил.

Что касается СУБД задач в которых некая навигация необходима, то они наверняка есть, только я их не встречал. К тому же абсолютно все задачи, решаемые на компьютере, могут быть решены средствами СКЛ+циклы (т.е. это фактически PL/SQL, Transact-SQL и т.д.) но без курсоров и конечно же без того убожества которое под навигацией понимает Андрей Леонидович и даже без использования ORDER BY.
5 авг 05, 00:40    [1765614]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Андрей Леонидович
Так что, mir и vadiminfo, мы уже закончили с "ролью ключей в РМД" ?
И вы со мной согласились ?
И можно переходить от идентификации к навигации ?
Я про роль ключей ничего еще и не говорил, следовательно и не могу с ней "закончить". А про навигацию мы уже несколько постов как пытаемся "беседовать". Опять косите под дурачка?
Итак, отметим первые итоги по вопросу о навигации. Определения нормального вы дать не в состоянии, ответить на вопросы и замечания не хотите. Пока так и запишем.
5 авг 05, 06:49    [1765724]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
vadiminfo
Member

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

К тому же абсолютно все задачи, решаемые на компьютере, могут быть решены средствами СКЛ+циклы (т.е. это фактически PL/SQL, Transact-SQL и т.д.) но без курсоров

Скорей всего, PL/SQL без курсоров вряд ли сможет использовать результаты SQL. Но это не имеет прямого отношения к навигации в большинстве случаев, поскольку курсоры указывают на результат SQL и нужны как механизм работы PL/SQL с монжеством записей. Если тока c помощью SQL не смогли получить нужного результирующего множества. И нужна еще обработка, чтобы таки получить нужный набор.
Но представляет интерес именно с помощью языка БД - SQL или навигационного получить этот результирующий набор данных из БД. Т.е. что предпочтительней реляционны доступ или навигационный в тех или иных случаях. Поскольку за доступ к данным отвечают они - выразительная сила системы запросов.
Хотя SQL в отличии от навигационных обеспечивает произвольные запросы, которые не предусматривали на стадии проектирования. Навигационный язык БД всегда внедренный. Т.е. тока в теле тех или иных языков программирования, а не сам по себе как SQL. Поэтому непосредственно навигационный язык сам по себе не претендует на сравнение с SQL.
Тем более, речь не идет о том, что в РСУБД не обеспечена вычислительная полнота.
5 авг 05, 19:53    [1768855]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
serg99
Member

Откуда:
Сообщений: 422
vadiminfo
Хотя SQL в отличии от навигационных обеспечивает произвольные запросы, которые не предусматривали на стадии проектирования. Навигационный язык БД всегда внедренный. Т.е. тока в теле тех или иных языков программирования, а не сам по себе как SQL. Поэтому непосредственно навигационный язык сам по себе не претендует на сравнение с SQL.

В общем то и на SQL можно писать навигационные запросы. И на OQL. Просто объектные базы имеют потенциал выполнять такие запросы быстрее. В то же время ООСУБД способная не хуже РСУБД (или хотя бы не намного хуже) выполнять нерегламентированные запросы SQL, несомненно привлечет к себе внимание.
5 авг 05, 21:38    [1768971]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множест  [new]
c127
Guest
vadiminfo
c127

К тому же абсолютно все задачи, решаемые на компьютере, могут быть решены средствами СКЛ+циклы (т.е. это фактически PL/SQL, Transact-SQL и т.д.) но без курсоров

Скорей всего, PL/SQL без курсоров вряд ли сможет использовать результаты SQL.


Результаты полученные в СКЛ запросе лучше всего использовать в другом СКЛ запросе. Но можно обойтись без курсора, одними переменными, если сначала сказать DISTINCT, а потом в цикле менять критерий запроса или использовать временную таблицу, то можно перебрать все множество и при этом на каждой итерации будет возвращаться не более одной записи. Т.е. переменных будет достаточно. А если использовать "select top 1" (в оракле по-моему аналог это rowcount=1), который совершенно реляционный оператор, то все гораздо проще, тогда критерий менять не нужно, выбирайте по одной записи, складывайте во временную таблицу, которую в зпросе использовать в "not exists", в результате переберёте все множество. Для особо грамотных расшифровываю, что никаких предположений о совершенно необходимых первичных ключах и дажо о том существуют ли они, необходимые, не делалось.

Но это теория, на практике курсоры конечно же удобнее и быстрее, с этим никто не спорит.
5 авг 05, 22:56    [1769031]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
vadiminfo
Member

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

В общем то и на SQL можно писать навигационные запросы.

Ну, я писал и про рекурсивные и про запросы с междустрочными вычислениями. Их включают в SQL. Т.е. запросы для которых навигация выглядит предпочтительнее. Или Вы что-то другое имете в виду?

serg99

Просто объектные базы имеют потенциал выполнять такие запросы быстрее.

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

serg99

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

То что некоторые ООСУБД поддерживают такие возможности слышал. Но пока не очень представляю до какой сложности они себе это могут позволить.
Ведь в РСУБД за этим стоит рел алгебра. Наверное, если ООСУБД использует маппинг на РСУБД или как бы представляет набор объектов одного класса как отношение с атрибутами соответствующими членам класса (типа "отвлекается" от того что это коллекция), то возможно, она может использовать почти SQL. Потому что там появляется реляционная структура. И стало быть можно использовать операции для таких структур из SQL. Но ведь ради этого она что-то должна потерять? Или такая ООСУБД приближается к ОРСУБД? Или нет?
5 авг 05, 23:12    [1769043]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
Андрей Леонидович
Guest
Потешно наблюдать за вашими обсуждениями, господа "реляционщики". Одна вечная морока "суррогатные или естественные ключи". Другая вечная морока "с курсорами или без курсоров"... Одна сплошная морока - эта РМД. Даже "Р"СУБД не спасают. Искренне сочуствую...
5 авг 05, 23:12    [1769044]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
vadiminfo
Member

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

складывайте во временную таблицу, которую в зпросе использовать в "not exists", в результате переберёте все множество.

Временная таблица - тоже таблица, и стало быть опять понадобится курсор. По крайней мере в Оракле. Там всегда создаются курсоры - и для одной записи. Наверное, тада уж лучше в коллекцию запихивать.
Если использовать запросы, которые возвращают по одной записи, то теоретически курсоры не нужны. Но тада может быть потеряна мощь, а может и смысл в SQL.
В PL/SQL SELECT INTO может засандалить в переменную коллекцию сразу набор значений за один раз, по крайней мере с 9 версии Оракла. Но при этом создается неявный курсор. Может его можно было и не создавать. Т.е. если стоит задача избавиться от курсоров, то можно прийти сразу к коллекциям, у которых методы значительно более богатые в плане навигационности, чем у курсора (навигация для него слишком громко сказано, по крайней мере в Оракле). Но это просто более продвинутый язык "третьего" поколения (у которого есть коллекции) работает с SQL, но все равно что-то подное "навигационное" прорисуется. Тока и для курсора это просто итерации, а не навигация по доступу к данным. Они уже получены с помщью SQL при создании курсора. Так что он, в общем, случае врядли олицетворение навигации и отхода от РМД. В худьшем случае это просто поддержка SQL в плане вычислительной полноты.

Коллега ЧАЛ не отличает навигацию в языке БД от итераций в приложениях, потому что у него вся модель данных в этих приложениях и все перемешано в одну кучу. Он не делит опреации на доступ к данным - систему запросов и функционал приложения.

Тут вопрос в том, что данные получены с помощью SQL (или другого реляционного языка БД) и никак иначе. Вот если бы открыли файлы, и начали лазить по записям, например, на низком уровне - вот отошли от РМД, так отошли. Или с МУМПСом коллега ЧАЛ прицепился как-то там без SQL. Хотя не знаю как. Поэтому я скептически отношусь к идее связи курсоров с отходом от РМД. И не вижу причин даже в теоретическом отказе от них, кроме случая если придумают что-то лучшее, или усовершенствуются языки "третьго" поколения. Но БД должна поддерживать как можно больше языков и, в том числе, у которых нет коллекций.
6 авг 05, 00:11    [1769093]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
vadiminfo
Member

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

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

А что Вам еще остается? Ключей нет - есть хорошо спроектированное приложение, на языке "третьго поколения" с массивами. Интегрированный - все в одной куче. Курсоров нет, потому что нет и языка БД четвертого поколения. О независмости приложения от данных речи нет. Остается тока одурачивать парней с балабановской спичечной фабрики, чтобы они на это клюнули. Я тоже несколько сочуствую Вам. Такие задачи не пожелаешь никому.
6 авг 05, 00:24    [1769105]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
serg99
Member

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

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


vadiminfo
То что некоторые ООСУБД поддерживают такие возможности слышал. Но пока не очень представляю до какой сложности они себе это могут позволить.
Ведь в РСУБД за этим стоит рел алгебра.

Интересно а много ли алгебры стоит собственно за языком SQL?


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

С ходу не видно почему ООСУБД должна что то потерять. Конечно нельзя будет в лоб выполнить сложные запросы написанные для РСУБД (в том числе потому что по разному реализуются связи в БД), но мне представляется что вариант SQL для ООСУБД может быть даже более мощным и выразительным чем его теперешний вариант для РСУБД.
6 авг 05, 02:05    [1769143]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
vadiminfo
Member

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

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

Это предполагает упорядоченность множества, перемещение от текущей(его) записи (объекта) по указателям (адресам) у другой(ому)?


serg99

Интересно а много ли алгебры стоит собственно за языком SQL?

Ну не мало, если иметь в виду выразительную силу, ассоциативность, коммутативность алгебраических операций. Тем более он расширяется новыми, дополнительными операциями. При этом ORDER BY по отношению к таблам можно тоже считать просто выбором представителя из класса эквивалентности на множестве табл по равенству записей. А класс эквивалентности сопоставить с отношением. Он может дополняться групповыми и аналитическими ф-ями
Я уже не говорю про мат обоснование.


serg99

С ходу не видно почему ООСУБД должна что то потерять.

Если использует маппинг на РСУБД? Или как-то проецируется на РСУБД, чтобы применять что-либо подобное SQL? Например, выборку. Она по неволе должна "забыть" о коллекции, так как по отношекнию к выборке это просто неупорядоченное множество. Больше ничего для выборки не надо. Стало быть это изоморфно отношению с атрибутами того класса. Но у отношения можно взять проекцию. А что при этом получится из объектов? Что это за обрезанные объекты? Свойства коллекции не используются. Получаются объекты у которых нет класса. Да и хорошо ли классы с их наследованием и проч укладываются в рел таблицу? Ниче там не может пропасть? Или не так? Это типа мои предположения сходу.

serg99

но мне представляется что вариант SQL для ООСУБД может быть даже более мощным и выразительным чем его теперешний вариант для РСУБД.

За счет методов? Т.е. в них заложат всякие вычисления? Но в РСУБД во-первых, тоже можно ф-ии из SQL вызывать. А во-вторых мы можем считать ОРСУБД расширением РСУБД. Т.е. он тоже это может?
Или за счет чего он мощнее и выразителнее? Во всем остальном он похож в лучшем случае на подмножество по операциям за счет проектировния на отношения. Основным для ООСУБД ведь не зря считают навигацию.
А OQL - просто удовлетворение каким-то требованиям, чтобы было какое-то подобие SQL. А так одно из двух кажется лишним, если вариант SQL для ООСУБД мощнее. РСУБД обходится без навигации, тогда ООСУБД тем более обойдется - ведь там мощнее.
6 авг 05, 03:30    [1769150]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
serg99


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

С ходу не видно почему ООСУБД должна что то потерять. Конечно нельзя будет в лоб выполнить сложные запросы написанные для РСУБД (в том числе потому что по разному реализуются связи в БД), но мне представляется что вариант SQL для ООСУБД может быть даже более мощным и выразительным чем его теперешний вариант для РСУБД.


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

Есть ООСУБД VDS (теперь уже называется Versant Object Database), а к ней есть специальное средство Versant/SQL, которое позволяет обращаться к хранилищу с помощью стандартных SQL-запросов. Что теряется? Разумеется потери есть. Очевидно, что в SQL нет средств для ОО-взаимодействия с базой, поэтому и все объектные возможности через SQL-интерфейс недоступны. Для обращения к объектам (а не к их представлениям в виде таблиц) необходимо устанавливать еще одно соединение непосредственно с объектным хранилищем Versant минуя Versant/SQL. Подробнее специфику работы и взаимодействия VDS и Versant/SQL можно понять ознакомившись с документацией (прилагается к триал версии, доступной на сайте Versant).
6 авг 05, 15:00    [1769356]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
Андрей Леонидович
Guest
Знатный "фабрикант" vadiminfo оказывается хранит модель данных в приложениях !? Видимо так предписывает ему оракле (не сам же такую глупость придумал). Не удивительно, что на "фабриках" он с такой "технологией" понятно как был встречен, и теперь вот переживает... Вместо того, чтобы переходить на нормальные современные технологии...
6 авг 05, 20:13    [1769550]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множест  [new]
c127
Guest
vadiminfo
c127

складывайте во временную таблицу, которую в зпросе использовать в "not exists", в результате переберёте все множество.

Временная таблица - тоже таблица, и стало быть опять понадобится курсор. По крайней мере в Оракле.


Временная таблица испльзуется ТОЛЬКО в not exists, а заполняется классическим insert. Где Вы увидели курсор?

vadiminfo

Там всегда создаются курсоры - и для одной записи. Наверное, тада уж лучше в коллекцию запихивать.


Я не говорю как ЛУЧШЕ (и повторяю это в третий раз), я говорю как МОЖНО.

То что там внутри курсор никого не колышит, таблиц как множеств тоже не бывает, но мы говорим о внешнем уровне. Как это сделано внутри меня не беспокоит в данном случае.

Я всего лишь привел схему решения задачи так называемой навигации с помощью чистого СКЛ-я и циклов, и без ЯВНЫХ курсоров. Все остальные задачи навигации (определения которой все нет) можно свести к ней. Разумеется с точки зрения сторонников марксистко-ленинской теории такого решения нет и быть не может может никогда, поскольку "В РМД, а, следовательно, и в Р(без кавычек)СУБД навигации нет, по определению." Ну и ладно.

Еще раз повторяю, что язык СКЛ, дополненный циклами, т.е. это подмножество ПЛ-СКЛя или Т-СКЛя, является полным, им решается вообще любая задача, решаемая на компьютере. Курсоры в смысле полноты ничего не добавляют.
6 авг 05, 22:45    [1769619]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос.Чем отличается понятие отношения в РМД от одноименного понятия в теории множеств  [new]
vadiminfo
Member

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

Временная таблица испльзуется ТОЛЬКО в not exists, а заполняется классическим insert. Где Вы увидели курсор?

Я увидел PL/SQL - этого достаточно. Временная таблица используется ТОЛЬКО в not exists - не знаю насколько это выразительно.
Если можно избавиться от Циклов с ее помощью в PL/SQL для получения требуемого результата запроса, то это может иметь какое-то значение в плане чистоты, если нет, то ничего не меняет в раскладе. См. ниже.


c127

Я всего лишь привел схему решения задачи так называемой навигации с помощью чистого СКЛ-я и циклов, и без ЯВНЫХ курсоров.

Раз есть циклы, то должно быть какое-то множество - какой-то массив, который этот цикл обрабатывает. В этом массиве есть инфа из множества записей. Как бы Вы их не получали - по одной, с временными Только not exists. Это все равно что-то подобное курсорам, тока по другому полученное. Потому, что курсор всего лишь механизм работы в ЦИКЛе язвка типа PL/SQL.
Ну, будет другой способ для получения требуемого результата запроса к БД, не ограничивающийся только СКЛ-ем.

Суть таже - результирующее множество не получено с помощью СКЛ-я без ЦИКЛОВ в PL/SQL.
То что коллега ЧАЛ, наезжая на курсоры, перепутал следствие с причиной, ничего не меняет. Он в этом не рюхает и просто от куда-то вычитал, и сам додумал. Использование для задач где лучше подходит навигация (а вообще и без упоминания навигации - для обеспечения вычислительной полноты) языков программирования дополняющих СКЛ. Т.е. не хватает выразительной силы СКЛ.
Когда-то давно мы с Вами говорили об этом на примере транзитивного замыкания. Кроме того, если рассматривать вопрос в терминах того, что предпочтительней в том или ином случае, т.е. и в СКЛе можно, но сложнее, то Ваш способ тока ухудшает положение раз Вы не рассматриваете, что ЛУЧШе. Это обязательно нужно рассматривать.


Вот я два раза писал, что в Оракле 10 похоже эти Циклы пихнули в СКЛ.
Это да. Это ушли от PL/SQL (и тем более курсоров и всего подобного внутреннего у него там), так ушли. Вот скоро поставлю 10 - посмотрю, шо це такэ. Но тоже перекрыли наверняка не все, особенно если смотреть в плане что ЛУЧШе.

c127

Еще раз повторяю, что язык СКЛ, дополненный циклами, т.е. это подмножество ПЛ-СКЛя или Т-СКЛя, является полным, им решается вообще любая задача, решаемая на компьютере. Курсоры в смысле полноты ничего не добавляют.

Он то полный, иначе бы он может и не нужен был. Тока дело не в курсорах а самих циклах в подмножестве ПЛ-СКЛя. В них "нереляционность", если переводить мысли коллеги ЧАЛа на обычный язык в технологиях БД.
Еще раз, однако, напомню, что мы об этом недостаке говорили когда-то давно. Я его приводил наряду с другими, но, конечно, не как критический для РСУБД. Во многих задачах он не проявляется, или его влиянием можно пренебречь.
7 авг 05, 13:54    [1769726]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить