|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Sergey Pratбh 2:5020/400 28 Jun 2001 12:54:49 To : All Subject : Hа: Cache -------------------------------------------------------------------------------- Hi! "Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее: news:9hcghj$nbv$1@host.talk.ru... > Что за манера - говорить на темы, в которых плохо смыслишь? :( Вроде никто > за язык не тянул... Опа, опа - Павликов был в ударе, как всегда... > > 1. Реализации _разные_ даже внутри каждой модели. Поэтому говорить о модельной > "физической реализации" - бред. Сказать честно не понял, бред - обсуждать вообще физическую реализацию как таковую или просто сравнивать их? > 2. "Основная масса запросов" - это и есть флейм чистой воды. У кого основная? :( Включи профайлер/анализатор и посмотри что составляет основную масу запросов. > 3. При одной и той же физической реализации реляционный запрос будет самым > _HЕ_эффективным. Hеважно, в десятки раз или на единицы процентов. За исклю- > чением относительно небольшого количества видов, где эффективность одинакова. Ты меня прости, но эта фраза - действительно полноценный бред. > 4. Прямой доступ есть везде - иначе как работать разработчикам? И он может быть > предоставлен и пользователям, хотя реляционным его и не назовешь. Разница > моделей именно в модельных же механизмах, о которых не упомянуто (по незнанию?) Вся эта каша потому, что кое-кто выдает желаемое за действительное. Я могу поверить в то, что кто-то в этом мире ошибается. Hо в то, что вся отрасль занимается садомазохизмом, мучаясь с реляционной моделью, когда под боком лежит такой клад как сетевая модель - нет, не могут все сразу сходить с ума. И на счет прямого доступа через API ко всяким Seek&etc - по своему опыту могу сказать, что движок DAO (MS Access) позволяет выполнять такие операции. И действительно поиск записи по ключу, вместо аналогичной выборки через SELECT дает выигрыш, но вот странный эффект получается: общая производительность приложения падает. Если бы было иначе, то по сей день, все крупные проекты писались на чем-то клипероподобном. -- С уважением, Сергей Прач ================= Please, send you private mail to: s_pratch@mail.ru --- ifmail v.2.15dev5 * Origin: Solver Ltd. site #2 (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/15014b2251496.html, оценка из 5, голосов 10
|