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

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

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

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

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

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

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

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

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

ModelRвверх(владелец), влево(предшествующий), вправо(следующий)

ИМХО от таких операций пользы меньше чем проблем. влево-вправо жестко закрепляют порядок обхода дочерних элементов, оптимизатор уже не сможет балансировать индексы, либо ему придется вести индексы дополнительно к двусвязанному списку. операция определения владельца не позволит реализовать гаммовский паттерн flyweight. В текущей версии моего изделия операции влево-вправо не поддерживаются. В разрабатываемой в данное время так же отсутсвует поддержка операции определения парента объекта.

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

MX -- АЛЕХ
можно ли на основе Вашей СУБД сделать нечто подобное
нашей системе MX - то есть вся бизнес - логика сидит в ячейках
excel на клиенте и из ячеек выстреливает серии запросов к базе данных
а затем полученный ответ отображает на этом же excel-листе ?
Хотелось бы применить - у нас проблемы с дороговизной
лицензий для M - продукт массовый и неплохо идет по 500 EUR,
но хочется снизить цену для мелких пользователей


Привет, здесь есть несколько ответов, от категорического да, до категорического нет. Основная загвоздка, я сделал _ядро_ субд, а не всю субд и это ядро пока _однопользовательское_. В пределах этих ограничений да, категорически можно. (Еще всплыли проблемы реализации в текущей версии с удалением объектов в пределах транзакции) Но эти ограничения как я и сам понимаю, вытесняют мою субд в сферу исследовательских проектов.

С экселем в подобном сценарии мы как то делали связку с ораклом, заказчикам нравилось до истерики. Собственно Ц во многом инспирирован этим моим опытом работы. Если забыть про ограничение на ядро, то опишу как бы такое можно было бы провернуть на основе Ц.

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

У меня в планах, возможно начну осенью, перевести locnet на Ц (ссылки на locnet я тут уже постил). Так как Ц можно рассматривать и как большой сервер сайд эксель, то всю бизнес логику, формулы, транзакции и пр. можно держать на сервере. а отображать на клиенте, в том числе и в виде матрицы похожей на эксель.

В перспективе, да, категорически можно, мало того, будет сделано. на сегодня есть риск.

MX -- ALEXСпасибо
буду надеятся
==========
Алексей
Если облегченная версия допускает только однопользовательскую десктоп конфигурацию то посмотреть на Ц имеет смысл уже седня. ну есть там глюки, где их нету? ведь заворкароундить можно все. Может и найдете чего полезного для своей задачи. Если же распределенный режим обязателен - сорри, смотреть на Ц еще около года точно смысла нет.