 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Dmitry V. Liseev 2:5020/400 06 Feb 2002 19:40:49 To : Vladimir Pavlikov 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> From: "Dmitry V. Liseev" <dimik@infopro.spb.su> Vladimir Pavlikov <pvv@soil.msu.ru> wrote in message news:a3fbva$1dv8$5@ddt.demos.su... Hi! > По мне - "идеальная" картинка д.б. что-то вроде (по "слоям", снизу) : > 1. Физическое хранение данных (диск). Hаверное, это должны быть ориентированные графы, серверный язык низкого уровня для работы с этими структурами и способ обяснить серверу, как с точки зрения разработчика оптимальнее эти данные на диске размещать (соседние узлы имеет смысл держать рядом, чтобы эффективнее кэшировать). В "М-системах" это все есть, и мне нравится. Хотя там не графы, а деревья, но я постоянно сталкиваюсь с тем, что вынужден эмулировать граф с помощью нескольких деревьев. Ведь получение доступа к одним и тем-же данным при помощи нескольких индексов - есть навигация по графу. Так что графы будут более естественной структурой. > 3. Логическая схема - полносвязная сеть. Согласен. Hо нужно подумать о многопользовательском доступе и поддержке ссылочной целостности. Причем это должно выполняться ядром сервера, с подключением пользовательского кода лишь при необходимости. Это достаточно важный момент, ибо объект должен загружаться в память с диска лишь при возникновении потребности в нем. Если объекты будут всегда сами поддерживать ссылочную целостность на прикладном уровне, их код и данные придется постоянно держать в памяти. > 4. Декларативный [и процедурный] ONSQL (объектно-сетевой), доступный > и на сервере, и на клиентах (создаваемых _разным_ инструментарием). Вот тут сложнее. ;( Hаверное, отсутствие языка построения запросов и является основным тормозом создания подобной технологии. > 5. (Опционально) - языковый (для используемых инструментальных пакетов) > слой, "инкапсулирующий" БД в язык (библиотеку). COM/DCOM/COM+/CORBA ? Если средства разработки БД способны экспортировать ее внешний (клиентский) интерфейс в ODL, то это можно прикрутить к любому языку. ____________________________ С уважением, Лисеев Дмитрий. http://private.peterlink.ru/dimik/ PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73 --- ifmail v.2.15dev5 * Origin: Peterlink News System (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/207536248b2e6.html, оценка из 5, голосов 10
|
|
|