Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 48 49 50 51 52 [53] 54 55 56 57 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
okdoky
Member

Откуда:
Сообщений: 349
MGR: Спасибо. Оказывается одним SELECT FROM WHERE не обойтись? Здесь тебе и JOIN и GROUP BY и HAVING.
28 ноя 06, 14:39    [3461964]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

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

Вообще то дело в ЧАЛОвском браузере было, который он пытался в ядро своей ОСУБД. С этим так или иначе связано ппоследнее. Зачем Вы в связи с этим подбросили сюда Zigzag не ясно. Но луче объектного навигатора или что?
28 ноя 06, 14:41    [3461978]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
quot pavelvp
ЛП
Вообще-то можно. И даже нужно.
Вот эта фраза непонятна. Поясните, пожалуйста, почему можно и даже нужно.

Почему можно?
Ну наверное потому, что никем это не запрещено.
РСУБД - сама по себе, язык запросов - сам по себе.
Единственное, что требуется - чтобы в РСУБД был хотя бы один "полный" язык (5-ое правило Кодда). А в остальном - простор открыт.
Один и тот же язык запросов может быть в разничных РСУБД, одна и та же РСУБД может поддерживать разные языки запросов, как при этом можно утверждать, что нельзя разделять эти понятия - непонятно совершенно.
28 ноя 06, 14:46    [3462008]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, ЛП!
Ты пишешь:

ЛП
как при этом можно утверждать, что нельзя
разделять эти понятия - непонятно совершенно.
разделять можно.
отделять нельзя.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

28 ноя 06, 14:48    [3462020]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
ЛП
Доступ к методам класса - это задачи навигации?

нет. Прямой доступ к конкретному экземпляру класса скорее, в том числе и через "точечную нотацию". Типичный пример задачи, для которой навигационный метод доступа подходит как нельзя лучше - аллокация (распределение) ресурсов. В РСУБД она конечно тоже решается, предварительными выборками и последующей обработкой их при помощи курсоров.
28 ноя 06, 14:49    [3462026]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MGR
Member

Откуда:
Сообщений: 536
okdoky
MGR: Спасибо. Оказывается одним SELECT FROM WHERE не обойтись? Здесь тебе и JOIN и GROUP BY и HAVING.


Нет, однако Вы тоже одним GOTO и EXIT SUB не обошлись? :)
Могу без джойн написать. Могу и без HAVING. А вот без GROUP BY - не смогу
28 ноя 06, 14:52    [3462053]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
Мимопроходящий

ЛП
как при этом можно утверждать, что нельзя
разделять эти понятия - непонятно совершенно.
разделять можно.
отделять нельзя.

И отделять тоже можно.
SQL, например, совершенно спокойно отделяется от РСУБД вааще. Пример - Пристрелить freecell на машине GAMER
РСУБД без языка, правда, уже не бывает. Хоть какой-нибудь, а нужен.
28 ноя 06, 14:54    [3462069]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, ЛП!
Ты пишешь:

ЛП
Л> И отделять тоже можно.
Л> РСУБД без языка, правда, уже не бывает.
вот об этом и твердит Павел. :)

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

28 ноя 06, 14:56    [3462080]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
8|
Guest
MGR
okdoky
MGR: Спасибо. Оказывается одним SELECT FROM WHERE не обойтись? Здесь тебе и JOIN и GROUP BY и HAVING.


Нет, однако Вы тоже одним GOTO и EXIT SUB не обошлись? :)
Могу без джойн написать. Могу и без HAVING. А вот без GROUP BY - не смогу


ну если в этом и состоит проблема...

SELECT i.itemno, i.description, (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno)
FROM items i
WHERE (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno) > 10
28 ноя 06, 14:57    [3462091]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
Мимопроходящий
ЛП
Л> И отделять тоже можно.
Л> РСУБД без языка, правда, уже не бывает.
вот об этом и твердит Павел. :)

Прошу пардону за занудство, но Павел таки твердит про разделение, а не про отделение.
:)
28 ноя 06, 14:59    [3462113]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MGR
Member

Откуда:
Сообщений: 536
8|

ну если в этом и состоит проблема...

SELECT i.itemno, i.description, (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno)
FROM items i
WHERE (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno) > 10


Я так не могу :(
совесть не позволит! :)
28 ноя 06, 15:06    [3462175]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Вероятно я неправильно выразился.
ЛП
Ну наверное потому, что никем это не запрещено.
РСУБД - сама по себе, язык запросов - сам по себе.
Единственное, что требуется - чтобы в РСУБД был хотя бы один "полный" язык (5-ое правило Кодда). А в остальном - простор открыт.
Вот как раз 5-ое правило Кодда и имелось в виду. Язык запросов может быть сам по себе, а РСУБД без него - нет.
Один и тот же язык запросов может быть в разничных РСУБД, одна и та же РСУБД может поддерживать разные языки запросов, как при этом можно утверждать, что нельзя разделять эти понятия - непонятно совершенно.
Понятия то можно. Нельзя отделить РСУБД от языка запрсов. Что постоянно пытается сделать ЧАЛ, рассматривая РМД отдельно от языка запросов - т.е. нарушая одно из правил Кодда, со всеми вытекающими.
28 ноя 06, 15:13    [3462231]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ЛП
Мимопроходящий
ЛП
Л> И отделять тоже можно.
Л> РСУБД без языка, правда, уже не бывает.
вот об этом и твердит Павел. :)

Прошу пардону за занудство...
Об этом об этом :-) В следующий раз буду точнее высказываться.
28 ноя 06, 15:18    [3462265]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
okdoky
Member

Откуда:
Сообщений: 349
MGR, 8|
автор
SELECT i.itemno, i.description, (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno)
FROM items i
WHERE (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno) > 10
Нет конечно. О такой конструкции я догадывался. Она не только не выразительная, но и работать будет медленнее.

Теперь сравним.
XQuery
for $i in items/item, $b in bids/bid[itemno = $i/itemno]
where count($b) > 10
order by $i/itemno
return {$i/itemno}; {$i/description}, {count($b)}
SQL
SELECT i.itemno, max(i.description), count(b.*)
FROM items i inner join bids b on  b.itemno = i.itemno
group by i.itemno
having count(b.*) > 10
И там и там задана операция выборки. На счет человечности трудно судить. Для меня первый запрос кажется проще. То же FOR WHERE RETURN я могу использовать и для более простых запросов. При этом все зависит от реализации. То есть навигация к записям, имеющим определенные значения, осуществляется не перебором, а через индексацию. Чем же тогда реляционные СУБД лучше в плане выразительности и быстродействия?
28 ноя 06, 15:35    [3462398]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
8|
Guest
okdoky
MGR, 8|
автор
SELECT i.itemno, i.description, (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno)
FROM items i
WHERE (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno) > 10
Нет конечно. О такой конструкции я догадывался. Она не только не выразительная, но и работать будет медленнее.


то была ваша же конструкция. из нее была удалена неудачная попытка джойна и вставлено вместо знака вопроса.
попробуйте это 8)

SELECT * FROM
(
SELECT i.itemno, i.description, (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno) cnt
FROM items i
) t
WHERE cnt > 10
28 ноя 06, 16:00    [3462642]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Dried Gagarin
Member

Откуда: Kaluga, Russia
Сообщений: 527
okdoky
То есть навигация к записям, имеющим определенные значения, осуществляется не перебором, а через индексацию. Чем же тогда реляционные СУБД лучше в плане выразительности и быстродействия?

не понял. "определенные значения" определяются произвольным образом, так? или существует ограниченное подмножество возможных "определенных значений"?
28 ноя 06, 16:29    [3462963]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
суперклон
Guest
Если Вы, ЗлОй, и дальше будете не задумываться над тем, что Вам говорят многочисленные клоны ЧАЛА, то так и не разберетесь ни в теории, ни в практике БД.
Ни "язык SQL", ни "Oracle Discoverer" не позволяют пользователям работать со схемой
Преподаватель<--Учит/Учится у-->Студент.
Практически все клоны именно работали и именно знают. Даже не надейтесь, и не морочьте людям головы.
Еще хуже с идентификацией. Вы (я, например, в этом уверен, хотя пара клонов еще сомневается) действительно искренне не понимаете, что именно отсутствие идентификации, проявляющееся в невозможности представления в РМД (и в "Р"СУБД)
объект(ид. экземпляра)=экземпляр
естественным образом приводит и к невозможности навигации. То есть невозможности для пользователей обращаться непосредственно к данным.
Все эти Ваши "с пол-тычка" оставьте для начинающих.
Лучше начинайте заниматься. Тем более, что мы уже подробно объясняли что нужно читать, на что следует обратить особое внимание, в чем заключаются проблемы и "реляционной теории", и общей теории баз данных. Проблемы многих "реляционных специалистов" заключаются именно в непонимании именно "реляционной теории". Потому что вместо изучения общей теории баз данных этих специалистов "затачивали" под "Р"СУБД и SQL. Потом всех начали "затачивать" под "парадигму ООП", не имеющую никакого отношения к базам данных. Человек станет свободнее, если между ним и информацией будут устранены искуственные барьеры в виде языков программирования и программистов (подобно тому, как в магазине самообслуживания нет барьеров между покупателем и товаром; но, интересно, что даже здесь есть ДВА "информационных барьера", что лишний раз подчеркивает важность того, о чем мы Вам говорим). Это может быть достигнуто и вне концепции баз данных. Нам же интересно пока решать эту задачу в рамках концепции баз данных. А для этого, как Вы, надеемся, понимаете, нужно разбираться в базах данных значительно глубже того уровня, до которого позволяет проникнуть знание "реляционной теории". Которое, к тому же, напрочь отсутствует у подавляющего большинства здешних "реляционных специалистов".
28 ноя 06, 20:08    [3464139]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, суперклон!
Ты пишешь:

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

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

28 ноя 06, 20:42    [3464201]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
суперклон
Если Вы, ЗлОй, и дальше будете не задумываться над тем, что Вам говорят многочисленные клоны ЧАЛА, то так и не разберетесь ни в теории, ни в практике БД.
Ни "язык SQL", ни "Oracle Discoverer" не позволяют пользователям работать со схемой
Преподаватель<--Учит/Учится у-->Студент.

Из этого утверждения я делаю вывод что с Oracle Discoverer вы не работали. Задать вам пару вопросов или сами признаетесь? Определение "схемы" со ссылкой на источник - в студию. В качестве источника приму любой серьезный учебник по СУБД.

суперклон

Еще хуже с идентификацией. Вы (я, например, в этом уверен, хотя пара клонов еще сомневается) действительно искренне не понимаете, что именно отсутствие идентификации, проявляющееся в невозможности представления в РМД (и в "Р"СУБД)
объект(ид. экземпляра)=экземпляр
естественным образом приводит и к невозможности навигации. То есть невозможности для пользователей обращаться непосредственно к данным.

Значицца так, мне надоела беспредметная болтовня. Приводите четкие и формальные определения "идентификации" и "навигации" с указанием источника. В качестве источника приму любой серьезный учебник по СУБД.

суперклон

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

Да ну! Интересно кто и как меня "затачивал" вот когда я писал на IMS + cobol на EC ЭВМ? Приведите что ли пару книжек по "общей теории СУБД", кого-нибудь из известных авторов . Сомневаюсь что у вас есть опыт работы с дореляционными СУБД и серьезные знания в данной области.
28 ноя 06, 20:57    [3464222]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Мимопроходящий

Привет, суперклон!
Ты пишешь:

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

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3


Я бы попросил ! :-))))
28 ноя 06, 21:50    [3464276]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
суперклон
именно отсутствие идентификации, проявляющееся в невозможности представления в РМД (и в "Р"СУБД) объект(ид. экземпляра)=экземпляр
естественным образом приводит и к невозможности навигации. То есть невозможности для пользователей обращаться непосредственно к данным.


Так это-то и хорошо, это-то и главное в реляционной теории ! именно отсутствие указателей, а как следствие, непроцедурность SQL , делает нашу жизнь легкой, а волосы - пушистыми. А на мумпсях пусть пишут мрачные субъекты с грязными, засаленными волосами (и непременно усыпанными перхотью ! ).
28 ноя 06, 21:53    [3464281]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
okdoky
Наличие навигации это плюс ...

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

okdoky
MGR, 8|
автор
SELECT i.itemno, i.description, (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno)
FROM items i
WHERE (SELECT count(*) FROM bids b WHERE b.itemno = i.itemno) > 10
Нет конечно. О такой конструкции я догадывался. Она не только не выразительная, но и работать будет медленнее.

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

Информация к размышлению: разные СКЛ сервера разные варианты одного запроса выполняют по-разному, уже не говоря о том, что соотношение количества строк в разных таблицах тоже имеет значение.


8|
iscrafm
в таблице А "курсор"(текущий контекст) установлен на записи с ид25, в таблице В на записи с ид2, в таблице С на записи с ид51. Без знаков равно понятно?

не понятно. какая запись следующая после ид25 и по какой причине.

ид74 конечно. Это же очевидно.

iscrafm
pavelvp
Навигация в РСУБД обеспечивается языком запросов. Запрос описывает "что?", "откуда?" и "как?" нужно получить.

Запрос в РСУБД выполняет операции над множествами, а не обеспечивает навигацию :)
чуть выше показан простешая навигация, на примере ObjectStore.

Запрос в РСУБД может обеспечивать навигацию в смысле определения ЧАЛ-а. Напоминаю, что ЧАЛ под навигацией понимал упорядочение множества. Нет ничего сложного, чтобы обеспечить такую навигацию SQL запросами. Ну и что дальше?

И еще один ворос: а много ли задач, где нужна навигация на сервере БД? Хотя повторяю, на СКЛ серверах навигация в смысле ЧАЛ-а есть.
29 ноя 06, 03:18    [3464608]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
c127

Запрос в РСУБД может обеспечивать навигацию в смысле определения ЧАЛ-а. Напоминаю, что ЧАЛ под навигацией понимал упорядочение множества. Нет ничего сложного, чтобы обеспечить такую навигацию SQL запросами. Ну и что дальше?


Ну тогда вообще проблем нет. Все что товарищ хотел это
select my_id, something
  from my_table
 order by my_id
чтоль?

Я то грешным делом думал что имелось ввиду что-то вроде
update my_table
  set my_column='new_value'
where current of my_cursor
Тут мы как бы имеем столь любимый многими указатель на запись. Вообще, пока не приведут определение "навигации" спор непонятно о чем. У Мартина я например такого термина вообще не нашел. Я не знаю где этот термин "нарыл" коллега ЧАЛ сотоварищи, поэтому как в классике по иерархическим и сетевым СУБД я определение этого термина не нашел.
29 ноя 06, 06:21    [3464662]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Dried Gagarin
Member

Откуда: Kaluga, Russia
Сообщений: 527
атака клонов... мой моск разрушен
29 ноя 06, 08:15    [3464763]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
okdoky
MGR: Спасибо. Оказывается одним SELECT FROM WHERE не обойтись? Здесь тебе и JOIN и GROUP BY и HAVING.


Оказывается одним group by не обойтись :( Нужно еще писать select
29 ноя 06, 09:02    [3464853]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 48 49 50 51 52 [53] 54 55 56 57 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить