Кэширование SQL запросов. как взрослые дяди делают это?

[Sad Spirit]

Автор оригинала: neko
Sad Spirit
не читай переводы

Я лучше не буду читать Фаулера. По прочтении его опуса у меня осталось стойкое ощущение, что меня на#бали. От прочтения в переводе же Буча и "Паттернов проектирования", что характерно, такого ощущения не было.

в оригинали не "термин отсутствует"
а "there isn't a widely used term"

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

relation это терминалогия гм, определенной группы лиц.
далеко не все знают что такое кортеж, отношение итп.

Человек, который Книги Пишет, в предметной области разбираться обязан и обязан использовать корректную терминологию. Заодно и читателей хорошему научит.

Там ещё много лажи, с ходу вспоминается потрясшее меня до глубины души откровение, что СУБД не умеют нормально оптимизировать запросы более чем по 3--4 таблицам.

про "хранимые процедуры отличающиеся табличным характером" я помолчу

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

-~{}~ 05.12.04 22:48:

Автор оригинала: wrapper
ИМХО кеширование результатов запроса это забота СУБД.

вопрос на 3 с плюсом: почему практически ни одна СУБД таковым кэшированием не занимается?

 

[wrapper]

вопрос на 3 с плюсом: почему практически ни одна СУБД таковым кэшированием не занимается?

встречный вопрос
если кешированием результатов запроса занимется не СУБД то откуда этому кеш-менеджеру знать что его результаты все еще валидные, т.е данные в базе не изменились?

 

[Sad Spirit]

Автор оригинала: wrapper
встречный вопрос

А почему ви отвечаете воп'осом на воп'ос? Ви таки да?

если кешированием результатов запроса занимется не СУБД то откуда этому кеш-менеджеру знать что его результаты все еще валидные, т.е данные в базе не изменились?

От приложения.

 

[neko]

субд не занимается кешированием запросов потому что это бессмысленно для субд
там есть 1001 место где можно оптимизировать работу (возможно даже за счет какого-нибудь кеширования)
зачем лезть в ту часть которая относится к приложению

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

-~{}~ 06.12.04 02:14:

Человек, который Книги Пишет, в предметной области разбираться обязан и обязан использовать корректную терминологию. Заодно и читателей хорошему научит.

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

 

[Wingely Dog]

2neko
"о! заговорил!" (С) 8)
можно мне непутевому, в нескольких словах разьяснить от этот абзац?

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

обещаю пересатать читать Фаулера в переводах 8)

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

-~{}~ 06.12.04 13:11:

neko
у тебя нету работы для морально-профессионального роста?
я вменяемый 8)

-~{}~ 15.12.04 07:37:

До меня доперло! Ей богу дошло.

Я неправильно мыслю! Мне это SQL кэширование и взаправду нафик не нужно! 8))