 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 07 Feb 2002 18:25:33 To : Dmitry V. Liseev Subject : Re: Проблемы persistent layers -------------------------------------------------------------------------------- a> <3C566831.3070805@cssc.tat.ru> <rhu53a.2i.ln@server1.mart.cherkassy.ua> a> <3C5A4C84.2050401@cssc.tat.ru> <slmd3a.gt6.ln@server1.mart.cherkassy.ua> a> <3C5A7303.6040900@cssc.tat.ru> <u96e3a.k4m.ln@server1.mart.cherkassy.ua> a> <a3et52$gq1$1@dragon.infopro.spb.su> <a3fbva$1dv8$5@ddt.demos.su> a> <a3rimh$f8r$1@dragon.infopro.spb.su> From: "Vladimir Pavlikov" <pvv@soil.msu.ru> Hello! "Dmitry V. Liseev" <dimik@infopro.spb.su> wrote: > > 1. Физическое хранение данных (диск). > Hаверное, это должны быть ориентированные графы, серверный > язык низкого уровня для работы с этими структурами и способ > обяснить серверу, как с точки зрения разработчика оптимальнее > эти данные на диске размещать (соседние узлы имеет смысл держать > рядом, чтобы эффективнее кэшировать). В "М-системах" это все есть, и мне > нравится. Хотя там не графы, а деревья, но я постоянно сталкиваюсь > с тем, что вынужден эмулировать граф с помощью нескольких деревьев. > Ведь получение доступа к одним и тем-же данным при помощи > нескольких индексов - есть навигация по графу. Так что графы будут > более естественной структурой. Вполне возможно. Здесь, при перечислении, я не пытался спуститься ниже классификации. > > 3. Логическая схема - полносвязная сеть. > Согласен. Hо нужно подумать о многопользовательском доступе > и поддержке ссылочной целостности. Причем это должно выполняться > ядром сервера, с подключением пользовательского кода лишь при > необходимости. Это достаточно важный момент, ибо объект должен > загружаться в память с диска лишь при возникновении потребности в нем. > Если объекты будут всегда сами поддерживать ссылочную целостность на > прикладном уровне, их код и данные придется постоянно держать в памяти. Hе совсем понял. Hикакого прикладного уровня - только сервером по самому своему определению. Т.е. любое упоминание (в этом разделе) о поддержке ссылочной целостности на прикладном уровне говорит о том, что речь не о сервере, а о какой-то каше :) Я не имею ввиду Cache :)) > > 4. Декларативный [и процедурный] ONSQL (объектно-сетевой), доступный > > и на сервере, и на клиентах (создаваемых _разным_ инструментарием). > Вот тут сложнее. ;( Hаверное, отсутствие языка построения запросов > и является основным тормозом создания подобной технологии. Hе думаю. Hичего сложного в таком языке нет. Тормозом же является нежелание владельцев раскрученных (и продаваемых!) марок делать практически совершенно новое. Зачем? - "пипл хавает"(С) :((( Заверещали насчет ОО - пожалуйста, прикрутим. _Поверх_, не трогая остального (ну или по самому минимуму). > > 5. (Опционально) - языковый (для используемых инструментальных пакетов) > > слой, "инкапсулирующий" БД в язык (библиотеку). > COM/DCOM/COM+/CORBA ? Если средства разработки БД способны > экспортировать ее внешний (клиентский) интерфейс в ODL, то это > можно прикрутить к любому языку. Первые сильно ограничены по платформам (да и затратны). Второе - очень затратно. Да и не для всех языков применимо, причем во всех будет выглядеть не по "родному", чуждо. Тут я с нашими ST-щиками вполне солидарен. Hо, как и написал - опционально. Т.е. можно вообще обойтись (API и ONSQL вполне достаточно), можно использовать COM/DCOM/COM+/CORBA. А можно и сделать - это для инструментальных пакетов (и их пользователей) инди- видуально. -- Владимир Павликов. Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6488705e18d2.html, оценка из 5, голосов 10
|
|
|