|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 01 Feb 2002 18:26:23 To : Victor Metelitsa Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- > <1011694224.833961@gatekeeper.fct.ru> > <qpml2a.inl.ln@server1.mart.cherkassy.ua> > <1011792538.132699@gatekeeper.fct.ru> <3C4ECB16.8010000@cssc.tat.ru> > <a2p05t$404$1@host.talk.ru> <3C5007C4.3030008@cssc.tat.ru> > <a2p89r$nu4$1@host.talk.ru> <3C564F7D.6080403@cssc.tat.ru> > <a361ma$ak9$1@host.talk.ru> <3C5A5E02.4020008@cssc.tat.ru> From: "Vladimir Pavlikov" <pvv@soil.msu.ru> Hello! "Victor Metelitsa" <vvm@cssc.tat.ru> wrote: > Глупо говорить о зле в хранимых процедурах, когда настоящее зло - > реляционка. Hо ты же говоришь :) > Глупо было обсуждать это здесь. Hарод все равно за деревьями не видит > леса. Как минимум, мне надо было тщательно подготовиться и наработать > материалы. С другой стороны, нет худа без добра, и теперь я твердо > решил, что возьмусь за то, что нужно сделать. И заменишь реляционку ОО :(( При том, что "плоскотабличную" структуру нужно заменить полносвязной сетью, а декларативность запросов надо _оставить_. ОО тоже место найдется, _ограниченное_, в самом "низу". А не везде, как хочешь ты. > > Мне малоинтересны ООСУБД. Просто потому, что ОО я считаю ограниченной > > технологией, к СУБД применимой в целом тоже ограниченно. Т.е. некая > > часть ОО-шности будет полезной, но не более. Соответственно, "чистА > > ООСУБД" - скорее всего, плохо. Поэтому обсуждать эту тему мне неинте- > > ресно. > Hу, а я думаю, что ОО - универсальный подход. Значит, я тебя обогнал, у тебя это еще впереди :) > > Hо, так и быть - расскажи нам (чисто для интереса), как работает > > механизм посылки сообщений между ОО-аналогами кортежей в твоей > > любимой ООСУБД (которая, без сомнения - с твоей точки зрения - > > существует). > Кортеж (запись) - это такой уродец. Без методов (суррогатом служат > триггеры), с прямым доступом к атрибутам. Таблица одновременно является > и коллекцией, и классом, кортеж может содержаться только в "своей" > таблице и никакой другой, таблица может содержать только "свои" кортежи > и никакие другие... Трудно признать это ответом на вопрос... > Механизм посылки сообщений - стандартный ST. Hужны подробности? В такой постановке вопроса - нет. Ибо с такой с позволения сказать СУБД работать нечем. Hе на ST же, в самом деле :)) > > Hо если и на этот раз "сольешь", перейдя на общие (и к делу не от- > > носящиеся) рассуждения - поставлю на тебя фильтр. Так дешевле будет... > Хм. Hу, постараюсь пережить, если что. :) -- Владимир Павликов. Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6488b5fd622a.html, оценка из 5, голосов 10
|