4d_monsterИмел ли кто дело с с етевыми СУБД?
С какими?
Какие впечатления?
Ссылки?

Что означает термин "сетевой" - в смысле "распределенные" или "не реляционные" ?

4d_monsterСетевые - которые требуют для работы питания от сети 220.

Я вот и хотел "разузнать" для каких случаев.

Вот видите, некоторые понимают под сетью граф, некторые - локалку, а теперь оказывается те, которые без батареек, только от 220. Я предлагаю посмотреть в сторону трехфазных сетей, 380 будет помощнее.

modСетевые, shuklin, я так поял это которые не иерархические и не реляционные.... Увы, это счас экзотика. Не имел, хотя в некоторох случаях наверное крайне эффективно...

Если те, которые не реляционные, то я сейчас как раз разрабатываю такую СУБД: Cerebrum : Система управления сетевой объектно-ориентированной базой знаний. С текущим прогрессом разработки можно ознакомиться по этому адресу: http://www.shuklin.com/ai/ht/ru/cerebrum Большая часть системы доступна в исходных кодах.

Gluk (Kazan)Бу Га Га

А Вы уверены, что она ИМЕННО сетевая, а не иерархическая ???
Фундаментальная наука, блин

Я то уверен. А какие у вас есть причины подозревать мою БД в том, ее модель не позволяет представить орграф с раскрашенными ребрами?

Gluk (Kazan)Я бы сказал, ДНК (я за научный подход)
Вот пустомеля. Хоть бы раз что нибудь технически конструктивное написал Стыдоба

Gluk (Kazan)
и про то что совсем забесплатно каждый может стать твоим бета-тестером


Ну так должен я хоть что то с альтруизма поиметь. Кстати, я здесь тоже отдыхаю. Только меня прет от конструктивного отдыха. К примеру новую ОМД продвинуть вместо старой РМД

vadiminfoЭто новое было новым 15 лет назад. Опоздали Вы. Тада было много таких надежд. А теперь поздновато.

15 лет назад небыло компонентных технологий. Небыло сборщиков мусора в стиле Java | .NET того же .NET тоже небыло ...

Все новое это хорошо забытое старое. Да. Я хочу восспользоваться старыми идеями (семантическим сетям более 50 лет, клеточным автоматам тоже более 50 лет, нейронкам Маккаллока-Питтса более 60 ти ...) Но реализовать эти идеи с помощью современных технологий. Ну и от себя добавить немного.

vadiminfo А то и с нейронками отстаните - их применят РСУБД (ОРСУБД) - которые будут универсальными серверами.
Я понимаю, что Вам хочется поразить мир. Но Вы, мне кажется, выбрали не удачное направление главного удара. 15 лет назад это направление давало шансы. Версанты и проч там все что можно выберут - Вам врядли что оставят. Большая фора по времени у них.

Модальность не та. Я использую нейронки моей собственной модели. У них таких быть не должно ;))) Просто маловероятно, что они пойдут по пути http://www.membrana.ru/articles/readers/2004/12/17/222900.html Следовательно вопрос заключается не в том, что у них есть уже тоже что и у меня - нету у них ))) А в том, возможно ли в том направлении научных исследований, которое я выбрал добится более интересных результатов чем в тех направлениях, в которые ринулись массы. Cerebrum - это инструмент который нужен мне лично для продолжения моих исследований по темам http://www.shuklin.com/ai/ht/ru/cybernetics.aspx и я буду продолжать его развивать независимо от любых обстоятельств ;)))

Вобщем я надеюсь, что те тузы, которых я припрятал в рукаве окажутся козырными, но вытаскивать их в течении нескольких лет я не намерен. А вот поделится тем что уже работает, услышать критику - этим и занимаюсь в данный момент. И выбираю направление следующего удара. Толи развивать ядро в сторону поддержки транзакций (в том виде в котором они мне нужны в ИНС) или приступить к реализации нескольких приложений для конечных пользователей (ту же экспертную систему довести до ума. то что есть сейчас по адресу http://contest2005.gotdotnet.ru/Request/Apps/Other/168720.aspx , в плане модели ИНС не дотягивает даже до http://www.shuklin.com/ai/ht/ru/ai00004f.aspx и http://www.shuklin.com/ai/ht/ru/binary/elex4b96.zip , однако в плане технологическом и возможностей к дальнейшему развитию - Cerebrum на несколько порядков перспективнее)

Мало того. Наука вещь специфическая. Даже "отрицательный" результат тоже результат. И он ценен. Важно даже не то, кто круче, а просто определить ограничения того или иного способа. Панацей не бывает. В каком то частном случае вполне может оказатся именно моя нейронка самой эффективной. А то что все бегут не туда куда я - только увеличивает мои шансы на то, что я не изобрету чейто велосипед повторно. ;)))

Иван FXS- а "сетевая" БД будет хранить его в виде:
1: 2; 3; 4
2: 1; 4
3: 1; 4
4: 1; 2; 3

То есть "обычная" БД требует создания таблицы "Связи", в которой каждая запись описывает ОДНУ связь межд узлами, а "сетевая" БД требует создания "таблицы", в каждой "записи" которой - для ОДНОГО узла - хранятся ВСЕ его связи, буде их одна, две, или миллион.

Правильно?

Что касаестя моего изделия - да с одним коментом. "таблица" будет реализована в виде индекса. Тоесть каждый узел хранит свой собственный экземпляр индекса, в отличие от "табличной БД", где для всех узлов один индекс. следствия. мое жрет столько же или больше памяти на диске но при работе с отдельными связями работает не медленнее или быстрее чем табличный аналог.

Иван FXSИ - что ИНДЕКСЫ служат для более эффективного оперирования (доступа к) данным, хранящимся в таблицах (а не для хранения данных)? Здесь ситуация забавная. Даже РБД (например MS-SQL) умеют хранить данные в индексах а не в таблицах и могут выполнять запросы к таблицам основываясь на информации только из индексов, вообще без обращения к таблицам. В своем изделии я сейчас поддерживаю только индексацию указателей. Собственно коллекция указателей и есть индекс в том смысле, что реализационно структуры на основе которых реализованы коллекции указателей есть индексы оптимизированные для хранения Int32. Основное прогрессивное отличие моего изделия от рбд не во внутренней реализации индексов и прочего (и ежу понятно что один человек не в состоянии оптимизировать все аспекты движка БД), а в другой модели данных. Если в РБД на основе таблиц можно эмулировать сеть, то у меня наоборот - на основе сети можно эмулировать таблицы. Поэтому свойства сетей и таблиц в моей бд несколько отличны от свойств сетей построенных на таблицах рбд. Ну оно как раз мне для СНС такое и нужно. И именно благодаря этому я и получаю основной выигрышь в скорости - благодаря отсутсвию дополнительного уровня абстракции необходимой в рбд для таблиц в сеть. Но выигрышь именно для интересующих меня задач. А для остальных задач мое изделие вполне сопоставимо по характеристикам с рбд хотя разумеется может уступать рбд на весьма большом классе задач.

Иван FXSДмитрий, а что будет индексировать этот индекс?

Обычно индекс "прилагается" к таблице. Индекс существующий сам по себе - это такая "улыбка чеширского кота"!

У меня индекс не существует сам по себе, он прилагается к каждому экземпляру объектов и индексирует аттрибуты данного экземпляра объекта. Другой экземпляр индекса прилагается к другому экземпляру объекта, и т.д. Тоесть каждый экземпляр имеет собственный экземпляр индекса своих аттрибутов. Как я уже писал, индексируются только указатели на аттрибуты а не содержимое аттрибутов.

Иван FXS
Если Вы говорите, что у Вас данные НЕ могут НЕ индексироваться, то есть хранение неотделимо от индексирования, то тут нет противоречия.


Именно, ну наверное ж если я это сделал и оно работает (проверяется путем давнлоада), то сделано енто одним из работоспособных способов, которых не так уш и много, ну чего надо обязательно понавыдумывать кучу неработающих интерпретаций моего сообщения а потом делать вывод что то что напридумано работать не в состоянии?

Эт раз.

И я говорил об индексации не значений аттрибутов а указателей на аттрибуты. Значения аттрибутов у меня храняться в сериализованном виде, а указатели на аттрибуты в виде индекса.

Сам индекс и предсавляет собой данные (указатели).

Иван FXS shuklinИ я говорил об индексации не значений аттрибутов а указателей на аттрибуты. Значения аттрибутов у меня храняться в сериализованном виде, а указатели на аттрибуты в виде индекса.
- дык, в чем состоит "индексированность" (хранения) указателей?

В том что указатели хранятся не сами по себе а в виде индекска. Индекс есть хранилище указателей а коллекция указателей есть индекс. Это одно и тоже. Тоесть что индекс что коллекция - это одна и та же структура данных. Как индекс она обеспечивает константное время поиска объекта по его указателю (разадресацию) не зависимо от колличества объектов в БД, а как коллекция хранит инфу об указателях на имеющиеся в БД объекты и позволяет выполнять операцию foreach.

Иван FXS shuklin Индекс есть хранилище указателей а коллекция указателей есть индекс. Это одно и тоже.
- Вы, наверное, хотите сказать, что доступ к объекту по его указателю не требует никакого "поиска в индексе", ибо по указателю объект доступен НЕПОСРЕДСТВЕННО ... но говорите это каким-то ж очень заумным образом!
Совсем никакого поиска увы не пройдет. Если мы говорим об ООБД а не об объектах в памяти, то объекты в ООБД должны иметь нечто типа Primary Key для обеспечения независимости от размещений в памяти, в хранилище и т.п. Эти ObjectID принято называть указателями - по аналогии с настоящими указателями, но без них получается гораздо сложнее реализовывать сборщики мусора и сериализацию.

Я в своем изделии несколько отошел от общепринятой практики, в которой каждый объект обязан иметь уникальный ObjectID, в глубине ядра я тоже имею уникальные ID для каждого объекта, но объекты идентифицируются по ним только в процессе сериализации. Клиент БД к ним доступа не имеет. Те ObjectID которыми оперирует открытое АПИ имеют несколько другие свойства. Так разные объекты могут иметь одинаковые по значению ObjectID - это позволяет выполнять операции JOIN разных объектов на основе равенства их указателей. ObjectID должен быть уникален для каждого дочернего объекта в пределах его парент объекта. Поэтому если взять два разных парент объекта, то у них могут быть два разных чайлд объекта с одинаковым ObjectID. Тут есть аналогия с РБД в которой можно JOINить строки из двух разных таблиц по значению какого то поля.

MX -- ALEX
почему MUMPS не подошел в качестве основы
для построения Вашего продукта ?

вообще все остальные СУБД (в том числе и M) не подошли по следующим причинам:

- я не являюсь владельцем их исходного кода, следовательно при необходимости шото там подкрутить это вызовет трудности.

- разработка была начата в 95 году, когда я понятия не имел о существовании М, или других систем, адекватных поставленной задаче. Теперь сворачивать будет дороже. Наверное наиболее близкий аналог к моему поделию по назначению это FramerD из MIT

- Основные задачи которые я собираюсь решать лично с использованием своей БД я буду решать на "глубинных уровнях", это даст мне дополнительный выигрышь в быстродействии.

- ну и косвенная причина - пусть будет много СУБД хороших и разных, одна из которых принадлежит мне ;)

Что касается лично M то как уже упоминали тут не раз, продвигают ее как то криво. Порывался ее выучить не однократно, но не тянет. И на сколько мне известно, M это всетаки БД, а мне нужна БЗ - тоесть в узлах у меня не данные а объекты с поведением (нейроны).