 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Victor Metelitsa 2:5020/400 23 Jan 2002 18:36:57 To : Ilya Zvyagin Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- > <1011694224.833961@gatekeeper.fct.ru> > <qpml2a.inl.ln@server1.mart.cherkassy.ua> > <1011792538.132699@gatekeeper.fct.ru> From: Victor Metelitsa <vvm@cssc.tat.ru> Ilya Zvyagin wrote: [..] > > В РСУБД мне не хватает _МЕТОДОВ_ объектов. Hо метод подразумевает под собой > инкапсуляцию данных, т.е. сокрытие внутренней структуры объектов и его > данных. Производительность РСУБД строится в основном на применении индексов, > т.е. специальной организации хранящихся данных. Тут как бы противоречие > намечается - как данные организовывать , если они скрыты ? Вот и получается, > что никак. А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном > от организации тривиального persistent storage для объектов приложения > достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем, > бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping. > Почему же никак? Чем в данном контексте обсуждения вызов метода объекта отличается от обращения к полю записи таблицы? Тремя вещами: фиксированным временем доступа и "детерминированностью" (т.е. если строка не подверглась модификации, то всегда получаешь один и тот же результат), а также "сравниваемостью" (две строки легко можно сравнить между собой, а как сравнить два объекта класса Employee?). Для метода это в общем случае не так. Hо если ты выделишь определенное подмножество методов, то индексы и оптимизаторы a la РСУБД вполне возможны. А ежели и ООСУБД этого не умеют, то их применение в чем-то отличном от организации тривиального persistent storage для объектов приложения достаточно ограничено, т.е. попросту ООСУБД слабо полезны в, скажем, бизнес-задачах. Я буду лучше использовать РСУБД и OOtoR mapping. Во-первых, ОО СУБД позволяют|ет (единственное число может быть, потому что для меня не факт, что есть более одной ООСУБД) делать _очень сложные_ структуры, прямо-таки немыслимые для РСУБД, простым и легким образом. Во-вторых, важность индексов тобой преувеличена - понятно, почему (потому что ты с ОО СУБД не знаком). Пример: X связан с Y отнощением 1:N. Типичное для РСУБД решение - две таблицы, foreign key, без индекса работа немыслима (чудовищные тормоза). У ОО СУБД экземпляр X попросту содержит ссылку на коллекцию экземпляров Y, с которыми связан. Таким образом, мы получаем искомые Y немедленно, без поиска по индексам. Еще одна чудесная штука - словарь (иначе называемый ассоциативным массивом). В нотации Java myDictionary[myIndex] myIndex - необязательно число, это может быть объект _любого_ класса. > > > -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/536401a3f7c4.html, оценка из 5, голосов 10
|
|
|