|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Ilya Zvyagin 2:5020/400 20 Jun 2001 10:43:37 To : All Subject : Re: Cache -------------------------------------------------------------------------------- Semen Cornetov wrote in message <992950767@p5.f18.n5022.z2.ftn>... >> если здесь есть представители кеша - может всетаки удасться >> получить ответ на вопрос годовой давности - как при простом! переносе >> реляционной модели на >> постреляционную! модель был получен выигрыш? Да нету там никакой постреляционной модели. Или объясните, в чем она заключается. К нам тоже из Кашей приходили, и то же говорили о повышении производительности. Я выяснил как. Короче, речь шла о БД ГАИ, БД должна была хранить номера машин и пр. лабуду. Вобщем, в одном случае ( уже не помню в каком ) им надо было сделать поиск по какому-то текстовому полю, ну скажем в 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у, так это и на любом существующем серваке можно изобразить при желании и большой необходимости. Hеумение писать программы никакими Кашами не исправишь. --- ifmail v.2.15dev5 * Origin: FCT Saint-Petersburg (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/13293b48b2523.html, оценка из 5, голосов 10
|