pkarklinЭээ... Помоему, Вы слабо себе предсталяете архитектуру современных серверов СУБД и в частности архитектуру кэша данных. Кэшируется то, к чему ЧАЩЕ ВСЕГО ОБРАЩАЮТСЯ! И это правильный подход, ибо нечего держать в кэше данные, которые ни кому не нужны. На счет связки данных... Кэширутеся то, в чем "есть большой спрос" и не важно, связаны эти данные или нет. Если чаще всего нужны данные из таблицы А, то они практически НИКОГДА не вытясняться из кэша. Аналогично и с данными таблицы В. При определенной потребности в них, они так же будут держаться в кэше. Сервер СУБД за это отвечает на уровне ядра. А Вы мне тут расказываете сказку про белого бычка, о кэшировании объектов на апп. сервере. Про кэширование планов выполнения запросов я уж и не смею упомянуть. Научились бы сначала исполь зовать возможности СУБД!!!

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

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

Про то что СП лучше потому что он СП - об этом по-моему никто и не говорил. А если и говорил, то он не прав.

tygra VladiCh Э... а по-моему прекрасно представляю. Мне не нужно кэшировать то, к чему ЧАЩЕ ВСЕГО ОБРАЩАЮТСЯ. Вернее тоже неплохо, но с этим действительно справляется и СУБД. Мне нужно кэшировать то, что постоянно вытаскивать из базы данных слишком медленно. Это в первую очередь. Независимо от того что думает СУБД на тему частоты обращения к этим данным.
Примерчик бы - что это такое, которое постоянно вытаскивать, но почему-то медленно. Если что-то постоянно вытаскивается, то в СУБД оно уж закэшируется обязательно. Или сами можете закэшировать, насильно :)
Тока что это такое, я не представляю.

Может чего не так спроектировано, что медленно получается?


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

systemR
жертва рекламы :( какая разница ну вылетит pl/sql объктная таблица из кеша, а у СП тот же объект свалится в своп, и какая в этом разница ? хотя нет разница громадна, объект СП неактуален, в то время как объектные таблицы pl/sql содержат всегда актульные данные и меняются в реал-тайме тригерами и прочей байдой.
При чем тут реклама? Это есть и работает. Насчет свопа рассмешил... А если СУБД не хватит памяти и она в своп упадет? Быстрее будет работать? Актуальность поддерживается без проблем.

systemRвместо того чтоб покупать под СП новый сервер, платить за винду/линух, $20K за iAs и прочее, а вложить это бабло в память серверу субд, то эфективность этого вложения будет несоизмерима.
Бр... При чем тут iAS? Я не собираюсь это барахло покупать. Можно конечно и память СУБД нарастить, не вопрос. Только это не решит вопрос ручного управления кэшированием, а не так, как этого захочет СУБД. Если только не загрузить базу данных полностью в память. Тогда конечно да... Не нарастите мне память сервера СУБД гигабайт до 200? Ну хотя бы до сотни? Во сколько это обойдется? :)