 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Victor Metelitsa 2:5020/400 23 Jan 2002 18:45:08 To : Ilya Zvyagin Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- Ilya Zvyagin wrote: > "Victor Metelitsa" <vvm@cssc.tat.ru> wrote in message > news:3C4E7DFB.4050809@cssc.tat.ru... 2. Определение (непонятно как) с каких > коллекций объектов надо начинать фильтрацию выборки. Для TOPLink'а/S: ты > создаешь описатель запроса, в котором указываешь класс и условия выборки. > После исполнения получаешь на клиенте коллекцию объектов этого класса (или > объектов подклассов этого класса). Это как-то оптимизируется, или же > перебираются все объекты этого класса ? Я же объяснил ниже - перебираются записи в реляционке. > >>Когда мы работаем с persistent-коллекцией, это выглядит так: >>someSesssion >> readAllFor: TEmployee >> where: [:eachEmployee | eachEmployee firstName = 'Dennis']. >>и запрос транслируется в >>SELECT какие-то поля >>FROM EMPLOYEE T1 >>WHERE T1.FNAME = 'Dennis' >>Строки, считанные из базы, превращаются в объекты. Hикакого FULLSCAN нет. >> > > А для чего-то отличного от тривиального свойства объекта как это будет > выглядеть ? Если firstName не соответствует напрямую полю РСУБД, а есть > результат некоей операции над полями ? Какую операцию ты хочешь? [:eachEmployee | eachEmployee firstName asUppercase = 'DENNIS' & eachEmployee lastName asUppercase = 'SMITH'] оттранслируются (в случае DB2) WHERE UCASE(fname)='DENNIS' AND UCASE(lname)='SMITH' в учебнике, ссылку на который я привел, есть более сложные случаи, с подзапросами и джойнами. > >>По-моему, тут есть два подхода. >> > .... > >>Второй утверждает, что никакой реляционной СУБД "нет". Мы уславливаемся >>считать, что PL+APP - это и есть СУБД (а реляционка, которая >>используется для хранения, мысленно низводится до уровня "умной дисковой >>подсистемы"). Все данные (объекты) по возможности загружены в >>оперативную память. Мне этот подход кажется наиболее симпатичным (пускай >>и требует много оперативки, и не всегда применим). >> > > и - перебор ВСЕХ объектов. Я понимаю, конечно, что и для РСУБД > такие нетриыиальные запросы тяжелы, но ... > Подумай по-другому. К примеру, ты твердо знаешь, что в твоей базе не будет больше гигабайта "чистых данных". Тогда, поставив на сервер, скажем, полтора гига, ты можешь держать в памяти их все. > Кстати, можно совмещать первый и второй. Hаверное это наиболее > реалистично. > Hаверное... -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/5364ad57b5eb.html, оценка из 5, голосов 10
|
|
|