FastDB/Gigabase не устраивают в первую очередь тем, что я хочу хранить коллекции ПОЛИМОРФНЫХ объектов. То есть наследников от базового. То есть коллекция характеризуется не фиксированным классом, а базовым - реально же помещаются его насдледники.

Процесс одни и сама сериализация проблем не вызывает. Проблемы вызывает организация и поддержка целостности ссылок между различными объектами разных коллекций. Думаю тепепрь моя проблема прояснилась ? ;)

Petro123Всегда стараюсь найти наиболее простое решение. Чем вас не устраивает такое:
id typ blob1 10 FFFFFFF0002 13 FFFFFFF0803 15 FFFFFFF060
Если тип объекта 13, то конструктор 13-го (типа фабрика классов). А объект сериализирует себя из BLOB.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Главная проблема - целостность ссылок. Как я организую хранения ссылок между объектами ?

ЗЫ Объём данных большой - хочектся максимально быстро всё организовать !

Petro123 авторГлавная проблема - целостность ссылок. Как я организую хранения ссылок между объектами ?
Чё то вы мудрите.
Вариант-статика (типа файла dfm у Delphi). При проектировании у каждого визуального компонента на форме-окне есть свойства owner и parent. При бросании на контейнер-объект автоматически записываются эти свойства. Все объекты умеют потом из потока (dfm/рессурса/бд сериализоваться). И обслужить дочерние и т.д.
Для того чтобы объект умел читаться из потока (файл/блоб БД) надо только наследовать его от базового умеющего это делать.
Механизм сериализации из потока везде одинаков , нодо тока синтаксис почитать и сравнить. В Delphi это 10 строк кода.
2 Вариант-динамика.
А кто мешает завести эти 2 свойства, коллекцию дочерних (их id) и выдернуть в конструкторе главного - дочерних из БД?
3 Вариант-деревья в РСУБД (вот тебе ссылки родитель-дитё).

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!


Обращение к базе/копирование блобов - операция довольно долгая, хотелось бы сразу получть указатель на объект, а не копировать большие куски памяти, как и будет происходить при считываении из РСУБД.

У меня много объектов - к примеру спокойно может быть выборка, за раз возвращающая 20000 объектов...

Petro123Обращение к базе/копирование блобов - операция довольно долгая, хотелось бы сразу получть указатель на объект================ Это как? Полная каша. Как получить значения полей класса для конструктора - не считывая их из файла/blob/db/потока? ))))).

, а не копировать большие куски памяти, как и будет происходить при считываении из РСУБД. ============ Вы вообще хоть один проект с БД делали?

У меня много объектов - к примеру спокойно может быть выборка, за раз возвращающая 20000 объектов...========= У меня миллион об-тов в БД. Но на клиента я тянуть стараюсь как можно меньше. Если клиент-серверная прога, то миллион об-тов должен сервер обрабатывать. Если нет, то
вообще храни их в оперативке и при закрытии сохраняй все в поток в двоичный файл.
Впечатление, что рассказав свою задачу, вы бы её решили гораздо грамотнее.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Приехали ....

а). Я делал не один проект с РСУБД и представляю как всё работает, так что давайте с уважением относиться друг другу - ок ? Если бы надо было сделать бухгалтерский ширпотреб, я бы воспользовался каким - нить MySQL и вопросов в этот форум вообще не постил.

б). Приложение НЕ клиент-серверное. База должна работать в контексте моего процесса и я прекрасно представляю, что запросив объект, база мне даст указатель на этот объект. Основная цель - не сериализация объектов, так как как раз эта проблема более-менее решена и объекты требует ся сохранять после закрытия приложения максимум в 10% случаев.

в). Нужно иметь функционал по простому и быстрому добавлению объектов в базу и простым выборкам этих объектов из базы. Для чего это нужно ? Что бы избавится от множества по разному реализованных коллекций, сделанных и создающихся разными людьми + каждый организует ссылки между объектами как ему вздумается, что приводит к большому количеству глюков захоламлению кода всяким отжнотипным мусором. Логичное желание - максимально упростить управление коллекциями и связями мужде объектами, сосредоточив шаблон в одном месте программы, что бы рядовой программист мог легко добавлять/удалять объекты в хранилищеи делать выборки по своему усмотрению. Объекты кстати постоянно добавляются новыеи естесвенно дрегистрация нового объекта должна осущесьвляться соврешенно элементарно.

Petro123Смею Вас уверить, что БД в процессе приложения (встраиваемое) достаточно быстро работает. Если вам надо:
- поиск SQL,
- сохранение после закрытия,
то пришли к тому от чего начали - 3 варианта.

Обращение к базе/копирование блобов - операция довольно долгая, хотелось бы сразу получть указатель на объект, а не копировать большие куски памяти, как и будет происходить при считываении из РСУБД. ============ При открытии проги считаете что вам надо (можете всё сразу). В inproc DB вы получаете указатель на BLOB. И что здесь будет длительного?

У меня много объектов - к примеру спокойно может быть выборка, за раз возвращающая 20000 объектов ...=============== Получишь 20000 указателей void для конструкторов объектов.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Да не хочу я ничего считывать при открытии базы ;)

Я хочу в процессе работы постоянно сохранять объеты/считывать. Если я буду регулярно дёргать их конструкторы, то кроме тормозов я других плюсов не получу + поимею все вытекающие проблемы с выделенимем динамическо памяти - операция длительная и постоянное выделение / освобождение памяти кучи небольшими кусками приведёт к фрагментации памяти и существенным тормозам - я уже смотрел профайлером по проекту - delete съедает основную массу времени - 8 %.

А я хочу тупо написать запрос - получить курсор, перебрать полученные объекты. То есть иметь доступ непосредственно к объектам, а не постоянно создавать из заново, дёргая их конструкторы. Повторюсь - я не хочу считывать объекты в свои контейнеры - свои структуру у меня и так есть - я как раз и хочу от них отказаться и переложить весь труд по работе с памятью/хранении объектов на базу. В принципе даже готов сам написать раз и навсегда.

Повторюсь - проблема не в сериализации объектов, а в динамическо работе с ними в процессе работы приложения.

Petro123 Ну дак и держи их в памяти. БД нужна будет только для поиска. Регистрируя об-т ты только записываешь id в своей коллекции в оперативке в БД и поля для поиска (Иванов Иван Иваныч). Раз не можешь искать в своей коллекции (или медленно там).
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

В этом то и задача что бы база держала их в памяти и управляла ими ! Если мне придётся и дальше возиться со своими коллекциями то мне база стороння тогда вообще не нужна.

Я хочу вообще отойти от своих коллекций - либо полностью написать аналог ООСУБД самому и тогда уж ни каким сторонним БД не обращаться... Для второго нужна серьёзная литература по оргпнизации структур данных/ООСУБД на С++, которой увы не могу найти :( А найти готовую БД удовлетворяющую моим требованиям увы пока не получается :(

Petro123Не от того пляшите. Надо от того что запрос сложный или нет. Мы взяли БД без поддержки SQL (сами парсер написали). Потом прокляли того который это посоветовал.
Если запросы сложные - SQL92 года, то не надо извращаться. Если простые, то не надо БД. У нас вообще двоичный файл был, по которому искали (в статике) и в оперативке (перебор коллекции).
автор
В этом то и задача что бы база держала их в памяти и управляла ими !================ Что значит управляла? Поиск?Сохранение?Индексация?Вставка?

Если мне придётся и дальше возиться со своими коллекциями то мне база стороння тогда вообще не нужна.=================== Вот и определись - зачем БД.

Я хочу вообще отойти от своих коллекций - либо полностью написать аналог ООСУБД самому и тогда уж ни каким сторонним БД не обращаться... ================== Лучше напиши операционку и не говори вслух громко.

удовлетворяющую моим требованиям увы пока не получается :(============= А ты ни одного требования не выдвинул - общие разговоры. Мне когда нач-к ставил задачу, я ему тест делал (MSSQL миллион объектов).
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Зачем БД я явно сказал - что бы хранить в ней объекты и выбирать их из неё по мере надобности - помещать новые - что непонятного ?

Хорошо, напишу псевдо код как это можно например представить на стороне клиента.

struct Point {
virtual Vector getPos() = 0;
virtual void setPos(Vector&) = 0;
virtual void draw() = 0;

reference<Line> refs;
REGISTER_REF(Line, refs);
};

class Point3D : Point {
int x, y;

public:
Vector getPos() {
// реализация
}

void setPos(Vector&) {
// реализация
}

void draw() {
// реализация
}
};

class SurfacePoint : public Point {
....
};

REGISTER_BASE_CLASS(Point);
REGISTER_CLASS(Point, Point2D);
REGISTER_CLASS(Point, SurfacePoint);


class Line {
public:
references<Point> refs;
REGISTER_REF(Point, refs);

void draw() {
...
}

void rotate(double angle) {
...
}
};

REGISTER_BASE_CLASS(Line);


main() {
int id1 = storage.insert<Point>(new Point2D(...));
int id2 = storage.insert<Point>(new SurfacePoint(...));

Line* line = new Line(...);

line.refs.addLink(id1);
line.refs.addLink(id2);

int lineId = storage.insert<Line>(line);

Query query;
// выбор всех точек, кторые ссылоются на заданный объект Line
query << lineId << db::in << " refs";
Cursor<Point>* cursor = storage("Point").select(query);

while (cursor->hasNext()) {
......
}
}


Коечно грубовато и не совсем последовательно - но общая идея что я хочу думапб понятна ;)

Petro123 авторЗачем БД я явно сказал - что бы хранить в ней объекты и выбирать их из неё по мере надобности - помещать новые - что непонятного ?
Терминология Ваша не точна - хранить объекты вы что подразумеваете?
- сериализация (вы говорите долго будет).
- ссылки на id объекта в коллекции в оперативке (ничего не говорите).
Вы пространственную БД делаете?
Пусть у вас векторная карта СССР (миллионы линий из точек). Вы её рисуете или что делаете? (зачем сразу вам 20000 объектов?).
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Объекты сами себя сериализуют - все объекты реализуют интерфейс
struct Serializable {
virtual void serialize() = 0;
};

Повторяю - вопрос сериализации меня беспокоит меньше всего. Главное - что бы все выборки/помещение объектов в базу (по сути оперативку = страничный файл) были быстрыми. Сама сериализация производится по выходу из приложения или запросе пользователя - но это случай как уже говорил не частый.

ссылки - я показал как мне хотелось бы видеть ссылки между объектами в пользовательском коде - как их реально лучше реализовать я не знаю почему и спрашиваю. Хотелось бы что ьы всем хозяйством заправляла база и порльзовательский код был максимально прозрачным и лаконичным.

Объекты нужны для САПР - системы - в часитности и для отображения трёхмерных моделей, но и для кучи всего остального

Petro123В MSSQL Server мне не хватает R-дерева и индекса по нему, что есть в Oracl (картриджем). Не случайно AutoCad подключается именно через этот механизм. Пришлось поиск делать ручками по габаритам объектов, но ничё - работает.
Скорость у тебя упадёт не там где ты думаешь.
Вот так как у БД Informix ты всё равно не напишешь:
http://www.jetinfo.ru/1997/12-13/1/article1.12-13.1997337.html#AEN347
В общем - удачи!

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

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

ЗЫ На сериализацию в принципе вообще можно забить - настолько это не важно. Все данные можно загрузить и через формирумый в процессе создания модели скрипт и подгрузка сформированных данных - полезная фича, но далеко не обязательная.

Petro123 авторя хочу полностью перейти на базу для динамического управлдени объектами
- если цель БД - быстро вытащить объекты (поиск без сериализации) по ссылкам и пространственным координатам, то это область - пространственая БД/R-tree.
- если цель БД - быстро вытащить объекты (поиск без сериализации) по SQL запросам, то это область - РСУБД.
- если цель БД - быстро вытащить объекты (поиск без сериализации) по SQL запросам, то это область - РСУБД.
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Что понимается под пространсвенная БД ?

Через РСУБД быстро вытащить объекты в принципе невозможно, как я уже говорил. Дёргать конструкторы объектов по тысячи раз за несколько минут, причём регулярно для одного ти того же объекта - это полный бред.

После того как я создал объект, он не должен пересоздаваться желательно ни разу за всё время функционарирования приложения, а если и долджен, то только если он очень редко используется.

Petro123Что понимается под пространсвенная БД ?========== В игрушки играли?
Карта и все элементы коттежда находятся в БД. БД строит пространственный индекс по координатам всех элементов/классов (линия, сфера, треугольник, стол из треугольников). При запросе движка к БД "дай мне все элементы в простанстве куба камеры (левая плоскость, правая плоскость, верхняя плоскость, нижняя плоскость)". По индексу R-tree БД выдаёт стол и автоматом все элементы стола , а также всё что пересеклось с кубом.
Из миллиона объектов БД ты отрисовываешь только видимые!
Простр-ая БД продаётся как отдельный коммерческий продут (MapInfo). Есть картриджем к Oracl и т.д.

Через РСУБД быстро вытащить объекты в принципе невозможно, как я уже говорил. Дёргать конструкторы объектов по тысячи раз за несколько минут, причём регулярно для одного ти того же объекта - это полный бред.=========== А зачем ты его уничтожаешь после первого дёрганья???????

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Зачем уничтожаю - а затем что если я считаю данные, то мне надо их потом сохранить в коллекции - а я принципиально НЕ ХОЧУ ничего никуда сохранять. Если посмотришь например FastDB от книжника - то как раз такой интерфейс работы с базой я и хочу. Но там свои минусы - приходится регистрировать все данные класса (я бы предпочёил тольке те кпо которым буду выбирать) и главное - все объекты должны быть конкретными класами, а я хочу полиморфные.

б). Нет, мне надо не пвыборки по пронстрансвенным координатам - ьребуются самы различные типы выьборок, но вся мощб SQL совершенно не нужна.