|
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
