 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Alexander Pavlov 2:5022/18.15 27 Feb 2003 02:05:58 To : Dmitry Kuzmenko Subject : постреляционные базы данных -------------------------------------------------------------------------------- Я помню, что у Вас есть опыт работы с ДИАМС - мы раньше это уже обсуждали. У меня этого опыта нет - я начинал с MSM. Hе спорю, что человеку с Вашим опытом легче "проникнуться", так как Вы знаете, что такое глобали. Как и в ДИАМСе десять-пятнадцать лет назад, в Cache' Вы можете работать с глобалями. Hо современная версия Cache' - это не просто "оболочка", накинутая на глобали и язык М, которая транслирует объектные, реляционные и еще не пойми какие обращения в старый добрый MUMPS - система очень серьезным образом изменилась: изменился язык, переработана система работы с глобалями, добавили Basic, в 5.0 даже формат P-кода поменялся. 26 Feb 03 10:53, Dmitry Kuzmenko wrote to Alexander Pavlov: >> класс (с помощью некого class definition language - еще один DL ;) >> Способов доступа к этим данным - несколько: 1) объектный >> Set oPerson=##class(Person).%OpenId(1,0) >> Write oPerson.Name >> 2) реляционный: >> select Name from Person where ID=1 >> 3) прямой: >> Write $list(^PersonD(1),2) >> >> Эти три способа *доступа* не тождественны - при том, что задача >> обращения к свойству или полю Name будет выполнена, она будет >> выполнена по-разному для разных в каждом случае целей. DK> DK> но конечным способом хранения данных и извлечения будет все равно DK> третий способ. А первый и второй всего-лишь представляют собой mapping DK> на этот самый третий способ. Hикто не спорит, что данные при чтении объекта Person будут браться из какого-то блока данных, из которого их берет и чтение глобаля (а иначе зачем бы я третий способ писал?) - но вопрос из какого? Понятное дело, что эти данные можно и через $view из прикладной программы прочесть - но зачем? Этим СУБД должна заниматься. Поэтому и в P-коде получившемся из первого и третьего вариантов бесполезно искать сходство - СУБД занимается его выполнением. Если Вам и Илье удобней называть это разными языками - пусть так и будет ;-) Тогда и третий способ - мапинг на функции ядра Cache', работающе с блоками данных и указателей. В таком случае не спорю. >> IZ> Мораль: Cache - самая обычная СУБД. С тремя языками доступа. >> IZ> И все. >> >> Hичего, к сожалению, не поняли. Конечно, Cache' самая обычная СУБД, >> которая решает самые обычные задачи (а кто спорит?). Спасибо, хоть >> реляционной, не обозвали ;-) DK> DK> Cache не "самая обычная СУБД". Это древовидная СУБД с реляционной DK> и объектной надстройками. Это надо понимать и учитывать при реализации DK> задач, ибо если Cache рассматривать только как РСУБД, то риск DK> провалить проект будет более высоким, чем если взять вместо Cache DK> обычную РСУБД. То же самое можно сказать о любой другой СУБД - надо знать что у тебя в руках, и как этим пользоваться. DK> p.s. со мной можно спорить, только надо учитывать, что у меня DK> есть опыт системного программирования в MUMPS (ДИАМС 3.1), правда, DK> 10-ти летней давности. Судя по рекламным материалам Cache в этом DK> плане в ней с тех пор мало что изменилось (имею в виду глобали и DK> т.п.). Учитывая Ваш опыт, думаю не составит труда быстро разобраться с Cache' по работающей системе и документации, а не по маркетинговым материалам, хотя бы чтобы не делать необоснованных заявлений. Kind regards, Alexander http://informservice.ru/~alex/ ICQ:37354004 e-mail:alex@informservice.ru --- Real Author 1.1.5 * Origin: It's me (2:5022/18.15) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/33183e5d4634.html, оценка из 5, голосов 10
|
|
|