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.