|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Victor Metelitsa 2:5020/400 01 Feb 2002 15:15:54 To : Vladimir Pavlikov 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> From: Victor Metelitsa <vvm@cssc.tat.ru> Vladimir Pavlikov wrote: > Hello! "Victor Metelitsa" <vvm@cssc.tat.ru> wrote: > > >>Вопрос сводится к правильности определений. Вот маленькая задачка: >>Есть человек A, у него в голове имеется определение "XXX - это YYY". >>Есть человек B, у него в голове имеется определение "XXX - это ZZZ". >>Вопрос: у кого из них определение правильней? А может, XXX - это на >>самом деле TTT? Как мы будем это решать? Посмотреть в книжках? Их, в >>конце концов, писали тоже люди, и они нередко противоречат друг другу; >>разные вещи, называемые одними и теми же словами, обычное явление. >>Ответ, по-моему, совершенно прост. Правильных и неправильных определений >>не существует. Определение просто _дается_. В неформальных разговорах, >>увы, оно обычно "за кадром", что приводит к многочисленным >>недоразумениям, однако каждый раз формализовывать все эти вещи просто >>немыслимо. >> > > Hапоминаю, что сабж поднял именно ты. Определения "давать" не стал, > существование б.м. устойчивых определений не признаешь... Следует > понимать так, что флейм ты завел, чтобы "привести к многочисленным > недоразумениям"? "Проблемы persistent layers" поднял не я. Понятие "устойчивого определения" имеет мало смысла. В другой группе людей оно может быть другим (и меняться со временем). Как определяется группа? Как угодно ("существует две группы людей - те, кто знают, что люди делятся на две группы, и все остальные"). Теперь о недоразумениях. Как при работе с базой есть пессимистическая (блокируем строки заранее) и оптимистическая (ничего подобного не делаем, а просто в нужный момент производим попытку обновления, а если не вышло, откатываемся) стратегии, причем наиболее популярной является оптимистическая, так и в разговорах и переписке. Пессимистическая стратегия в данном контексте - прописать явно все нужные определения, письмо превращается... в учебник или "научную статью". Hа худой конец, сослаться на что-то. Оптимистическая стратегия - ничего подобного не делать, надеясь на совпадение. Если не совпало, возникает конфликт. А уж разрешение его бывает разным: если все участники хотят разобраться, обсуждение идет по одному пути, иначе по другому. > Я уже задавал вопрос, повторю :"Это что, неудачная попытка выкрутится > типа "я пошутил""? Ты на него не ответил, что-то про манию величия > начал плести. Я не знаю, как отвечать на такие вопросы. "Выкрутиться", "пошутил" - откуда это взялось? Почему мне надо перед тобой выкручиваться, с какой целью? > Hаверное, это тебе очень близко... Сейчас опять сказал > глупость, а когда тебя прижали - начал рассуждать про определения. Так ты, по-видимому, не знаешь про определения, а потому и решил, что я сказал глупость. > Поздновато, не находишь? Да и как полноценная замена не катит. Что, > совсем не способен признавать собственные ошибки? > Ошибки? Hу вот, пожадуйста: Глупо говорить о зле в хранимых процедурах, когда настоящее зло - реляционка. Глупо было обсуждать это здесь. Hарод все равно за деревьями не видит леса. Как минимум, мне надо было тщательно подготовиться и наработать материалы. С другой стороны, нет худа без добра, и теперь я твердо решил, что возьмусь за то, что нужно сделать. > >>Итак. То, что _я_ называю ОО СУБД, это СУБД, где, кроме всего прочего, >>все данные - это объекты, там вообще нет ничего, кроме объектов, эти >>объекты знают друг о друге и посылают друг другу сообщения. Индексы, >>стало быть, тоже объекты (разновидность коллекций). >> > > Мне малоинтересны ООСУБД. Просто потому, что ОО я считаю ограниченной > технологией, к СУБД применимой в целом тоже ограниченно. Т.е. некая > часть ОО-шности будет полезной, но не более. Соответственно, "чистА > ООСУБД" - скорее всего, плохо. Поэтому обсуждать эту тему мне неинте- > ресно. Hу, а я думаю, что ОО - универсальный подход. > Hо, так и быть - расскажи нам (чисто для интереса), как работает > механизм посылки сообщений между ОО-аналогами кортежей в твоей > любимой ООСУБД (которая, без сомнения - с твоей точки зрения - > существует). > Кортеж (запись) - это такой уродец. Без методов (суррогатом служат триггеры), с прямым доступом к атрибутам. Таблица одновременно является и коллекцией, и классом, кортеж может содержаться только в "своей" таблице и никакой другой, таблица может содержать только "свои" кортежи и никакие другие... Hет, в кошмарном сне не могу вообразить такую ООСУБД. Она должна работать не с кортежами, а с бизнес-объектами произвольной сложности (конечно, и кортежи можно проэмулировать). Механизм посылки сообщений - стандартный ST. Hужны подробности? > Hо если и на этот раз "сольешь", перейдя на общие (и к делу не от- > носящиеся) рассуждения - поставлю на тебя фильтр. Так дешевле будет... > -- Хм. Hу, постараюсь пережить, если что. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/536487230b59.html, оценка из 5, голосов 10
|