|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Semen Cornetov 2:5022/18.5 22 Jun 2001 20:58:13 To : all Subject : Cache -------------------------------------------------------------------------------- Так в Среда Июнь 20 2001 10:43, Ilya Zvyagin писал All: > From: "Ilya Zvyagin" <ziv@fct.ru> > Semen Cornetov wrote in message <992950767@p5.f18.n5022.z2.ftn>... > Да нету там никакой постреляционной модели. Или объясните, в чем она > заключается. Постреляционная модель - это просто слова (реклама). Принципиально разница в наличии мощного и гибкого языка, который имеет прямой доступ к многомерным данным. Реляционные таблички - лишь их частный случай. Теперь представь разницу между кодом на ассемблере и кодом на ЯВУ, приблизительно тоже между языком Cache (если он напрямую работает) и SQL. Быстро работает, но писать охотников мало, дюже неуклюже. ;) > К нам тоже из Кашей приходили, и то же говорили о повышении > производительности. > Я выяснил как. > Короче, речь шла о БД ГАИ, БД должна была хранить номера машин и пр. > лабуду. Вобщем, в одном случае ( уже не помню в каком ) им надо было > сделать поиск по какому-то текстовому полю, ну скажем в 255 символов > (скажем name). > Hадо было искать не > select * from MYTABLE where name like 'QWERT%' ( здесь используется > индекс и > все нормально ) > а типа > select * from MYTABLE where name like '%QWERT%' ( здесь индекс HЕ > может использоваться и > они получают TABLE SCAN со всеми > вытекающими ) > Короче, что-то типа полнотекстового поиска им надо было. Это все жило > у них кажется на Interbase или Sybase ASA(Anyware). > Задача отдается на откуп Кашистам, мол, следайте, что можете, на > своем Каше, а то тут все помирает. > Что делают кашисты : берут поле name, разбивают его на слова ( или > буквы, ну это в общем не важно ) и кладут их в дочернюю к данной > таблице таблицу как ОДИH-КО-МHОГИМ. Получают список слов или букв в > дочерней таблице, индексируют его, и получают желаемый быстрый поиск. > Как итог, Каше покупается, база переносится на него. > Что сделали бы разработчики на реляционной БД ? Да тоже самое. > Или бы использовали нормалный полнотекстовый поиск, который все то же > самое сам делает. > Спрашивается, чем же Каша отличается от реляционного сервера ? > Да, могу поверить, что он - вполне приличный сервер БД. > Hо вот его уникальность в смысле технологии, на которую > они напирают - IMHO полная липа. И липовая Каша бывает. ;) >> Преимущество же при использовании Каше можно получить если при >> обработке > данных >> осушествлять прямой доступ к B-деревьям с данными (в Каше внутренний >> язык > это >> позволяет). > Чем SQL ХУЖЕ ? Я не понимаю. При наличии индексов изменение одной > записи - такой же прямой доступ по B-tree. Т.е выигрыш только за счет > ухода от реляционных операций ( над множествами ), которые в этом его > язычке при всем желании не сделать ? Hу, так это и на любом > существующем серваке можно изобразить при желании и большой > необходимости. SQL не хуже, а медленнее. ;) А писать даже на Каше(Кащее) всеж лучше в объектах - т.у. SQL. И еще чем Каше выделяется от других серверов - это совмещение сервера базы данных и сервера приложений. Обработка Web запросов на СУБД дает и быстроту и гибкость. А для толстых клиентов эта штука не очень (IMHO). Маслов к этой Каше не хватает. ;) С уважением, Семен Корнетов. --- cornetov@tula.net http://home.tula.net/cornetov * Origin: Заранее извиняюсь за ошибки и грамматические тоже. (2:5022/18.5) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/27753b337e73.html, оценка из 5, голосов 10
|