Объектная База не нуждается в таблицах и пр. т.к. она объектная!
Такой подход к проектированию обусловлен работой с РСУБД и ОРСУБД.
Объектная база данных позволяет использовать ПОЛНОСТЬЮ объектных подход к проетированию и последующей реализации баз данных.

А вообще моя коллекция ссыло лежит здесь. Там есть все реализации и много литературы.

Здравствуйте, BaZa, Вы писали:

BZ>А вообще моя коллекция ссыло лежит здесь. Там есть все реализации и много литературы.

Спасибо, однозначно в закладки. Однако ж давняя темя. Продукт, по поводу которого я затеял этот вопрос, совсем недавно зарелизился. К сожалению, ООБД там и не пахнет Тем не менее, почитать есть что.

Кстати, у меня в Опере билда 7364b на вашей страничке наблюдается баг -- выпадающие менюшки сдвинуты, и попасть в них нелегко Вот как это выглядит

Здравствуйте, BaZa, Вы писали:

BZ>Объектная База не нуждается в таблицах и пр. т.к. она объектная!
Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах.
Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти.
Или уже есть файловый GC ?????

Никто и не говорит про универсальность ООСУБД"ов...

Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, BaZa, Вы писали:

BZ>>Объектная База не нуждается в таблицах и пр. т.к. она объектная!
S> Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах.

Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться.
А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных. Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами).

S> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти.
S> Или уже есть файловый GC ?????

Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД.

Здравствуйте, BaZa, Вы писали:

BZ>Никто и не говорит про универсальность ООСУБД"ов...

BZ>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД.
Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях.

Здравствуйте, eao197, Вы писали:



S>>Здравствуйте, BaZa, Вы писали:

BZ>>>Объектная База не нуждается в таблицах и пр. т.к. она объектная!
S>> Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах.

E>Фишка в том, что в объектных БД объекты могут очень легко изменять свой размер. А хранилище должно с этим эффективно справляться.
E>А могут легко изменять свой размер потому, что в одном объекте может быть масса других объектов совершенно по разному организованных.
Прежде всего объекты это ссылки и поля имеют некую структуру позволяющие определить местонахождение объекта, но сам он должен оптимально хранится, иначе можно на такую фрагментацию нарваться. Кстати изменение размера достигается очень легко, если представить объект как некоторый связный список кусков определенного размера.
E> Например, объект может иметь в качестве атрибута вектор переменного размера из других объектов. Эти подчиненные объекты могут сами иметь в качестве атрибутов, скажем, множество других объектов и т.д. При отображении этого хозяйства в таблицы РСУБД требуются дополнительные усилия. А в ООСУБД объект сериализуется в двоичный блок и этот блок запихивается в файл хранилища. И, обычно, чтение/запись производится одной операцией, а не поиском нужных компонентов по разным табличкам (но и здесь возможны варианты, если ООСУБД поддерживает продвинутые ссылки между объектами).
Да уж представляю как некое дерево с миллионами вершин сериализуется и десериализуется. В данном случае я говорю лишь об оптимальном хранении объектов, а не доступе к объектам.

S>> Так любой менеджер памяти основанный на массиве порвет любой супер пупер универсальный менеджер памяти.
S>> Или уже есть файловый GC ?????

E>Конечно. У меня, например, хранилище реализовано так, чтобы переиспользовать место от удаленных объектов. И не нужно делать явных уплотнений файлов БД.
Это обычная оочень старая техника, которая применяется как в Менеджерах памяти, так и в БД.

Зачем так усложнять себе жизнь? не нужно думать о хранении на таком низком уровне. поэтому и покупаются коммерческие СУБД, чтобы переложить такие задачи на нее. Когда к нам приезжали специалисты Versant (обучать нас , мы тоже пытались показать им на каком уровне мы работаем (это был низкий уровень), так вот они пришли от этого в ужас. Не нужно делать ручками то, что за вас делает сервер БД.

Мне случалось работать с СУБД, где это было не так. Просто Вы привыкли
мыслить в терминах "таблиц".

Serginio1 wrote:

> Любой объект имеет определенный размер по определению, но поля могут
> иметь неопределенный тип.

Здравствуйте, TheBeard, Вы писали:

TB>Мне случалось работать с СУБД, где это было не так. Просто Вы привыкли
TB>мыслить в терминах "таблиц".

TB>Serginio1 wrote:

>> Любой объект имеет определенный размер по определению, но поля могут
>> иметь неопределенный тип.

А можно помотреть на объект (класс) неопределенного размера ?????
Про динамические свойства уже писал. Я в данном случае веду разговор об оптимальном хранении данных.

А реализаций может быть очень много например Re[5]: Объектно-ориентированные БД: основные принципы, орган

Автор: Serginio1
Дата: 04.03.05

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, BaZa, Вы писали:

BZ>>Никто и не говорит про универсальность ООСУБД"ов...

BZ>>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД.
S> Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях.
Современные СУБД могут хранить изменяющиеся по длине данные (см varchar в MS SQL, varchar2 в Oracle). Проблема не в хранилище. Проблема в инкапсуляции данных. Объект — это не просто набор полей сохраняемый в постоянном хранилище (как это описано в ORDB). Объект — обладает поведением, что не очень нравится реляционной алгебре.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:



BZ>>>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД.
S>> Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях.
GZ>Современные СУБД могут хранить изменяющиеся по длине данные (см varchar в MS SQL, varchar2 в Oracle). Проблема не в хранилище. Проблема в инкапсуляции данных. Объект — это не просто набор полей сохраняемый в постоянном хранилище (как это описано в ORDB). Объект — обладает поведением, что не очень нравится реляционной алгебре.
Хранение изменяющихся данных это не проблема, помнишь как хранятся длинные строки в 1С, правда легче хранить их как список.
На данном этпае я поднял именно проблему хранения, а не поведения объектов.
Считай это проблема менеджера файловой памяти.

Здравствуйте, Serginio1, Вы писали:

S> Или уже есть файловый GC ?????
Мало того. Во многих ООБД с помощью GC обеспечивается ссылочная целостность. Объект удаляется из базы после удаления последней ссылки.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Serginio1, Вы писали:

S>> Или уже есть файловый GC ?????
GZ>Мало того. Во многих ООБД с помощью GC обеспечивается ссылочная целостность. Объект удаляется из базы после удаления последней ссылки.
Основная задача GC не столько сбор мусора, сколько дефрагментация памяти, и сдвижки указателя на конец использованной кучи. И при всем этом объекты размером более 80 кб не подвергаются дефрагментации. А в БД могут существовать милларды объектов. И если идет много удалений то сочувствую пользователям данной БД

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:

GZ>>Здравствуйте, Serginio1, Вы писали:

S>>> Или уже есть файловый GC ?????
GZ>>Мало того. Во многих ООБД с помощью GC обеспечивается ссылочная целостность. Объект удаляется из базы после удаления последней ссылки.
S> Основная задача GC не столько сбор мусора, сколько дефрагментация памяти, и сдвижки указателя на конец использованной кучи. И при всем этом объекты размером более 80 кб не подвергаются дефрагментации. А в БД могут существовать милларды объектов. И если идет много удалений то сочувствую пользователям данной БД
Можешь точно так же посочуствовать и пользователям РСУБД. Удаление миллионов строк точно такая же, тяжелая операция (к тому же логгируемая).
Вообще сравнивать GC NET и GC какой-нибудь OODB очень неблагодарное дела. Они работают в разных условиях. Я не знаю в какой момент удаляется объект физически(асинхронно, или синхронно после потери последней ссылки), но GC так и остается GC. А дефрагментироваться и многие РСУБД умеют (иногда вынужденно).

С уважением, Gleb.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:



BZ>>>>Да, при таких условиях: Любой объект это всего навсего структура определенного размера,а хранить данные одинакового размера все же лучше в таблицах, лучше использовать РСУБД. А когда размер не определен (а есои и сама структура сама не определена) и пр. то вот тогда лучше использовать ООСУБД.
S>>> Я в данном случае говорю только об оптимальном хранении данных. Которые должна использовать ООСУБД. Любой объект имеет определенный размер по определению, но поля могут иметь неопределенный тип. Возможность динамического добавление свойств это сахар, основанный на коллекциях.
GZ>>Современные СУБД могут хранить изменяющиеся по длине данные (см varchar в MS SQL, varchar2 в Oracle). Проблема не в хранилище. Проблема в инкапсуляции данных. Объект — это не просто набор полей сохраняемый в постоянном хранилище (как это описано в ORDB). Объект — обладает поведением, что не очень нравится реляционной алгебре.
S> Хранение изменяющихся данных это не проблема, помнишь как хранятся длинные строки в 1С, правда легче хранить их как список.
S> На данном этпае я поднял именно проблему хранения, а не поведения объектов.
S> Считай это проблема менеджера файловой памяти.

Если ты говоришь о проблеме с variant. При выполнении запроса для многих операций нужна информация о типе. Ну не может быть построен план запроса, если нет точной информации о типе полей. Максимум что есть в РСУБД — LOB, с которыми практически ничего нельзя сделать. Разве что явно получить, и явно сохранить. Сейчас появились система хранения xml — но это уже отдельный механизм.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:


GZ>Вообще сравнивать GC NET и GC какой-нибудь OODB очень неблагодарное дела. Они работают в разных условиях. Я не знаю в какой момент удаляется объект физически(асинхронно, или синхронно после потери последней ссылки), но GC так и остается GC. А дефрагментироваться и многие РСУБД умеют (иногда вынужденно).

Дефрагментация для таблиц в большинстве и не нужно, т.к. обычно организуется список удаленных записей и используются повторно при вставке новой записи, хотя все зависит от организаци, может нужна вся история изменения записей
Если у тебя есть ссылочки на файловый GC какой-нибудь OODB буду очень благодарен. Меня это интересует чисто теоретически, для повышения умственного уровня. Нам 1С программистам без этого нельзя.

Здравствуйте, GlebZ, Вы писали:


GZ>Если ты говоришь о проблеме с variant. При выполнении запроса для многих операций нужна информация о типе. Ну не может быть построен план запроса, если нет точной информации о типе полей. Максимум что есть в РСУБД — LOB, с которыми практически ничего нельзя сделать. Разве что явно получить, и явно сохранить. Сейчас появились система хранения xml — но это уже отдельный механизм.

Глеб пойми меня интересует как организовано хранение данных в Объектно-ориентированные БД.
Меня РСУБД мало интересуют, я с локальными БД работаю в том числе и на прямую через API.
В конце концов хочу свою Объектно-ориентированные БД залудить

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:


GZ>>Вообще сравнивать GC NET и GC какой-нибудь OODB очень неблагодарное дела. Они работают в разных условиях. Я не знаю в какой момент удаляется объект физически(асинхронно, или синхронно после потери последней ссылки), но GC так и остается GC. А дефрагментироваться и многие РСУБД умеют (иногда вынужденно).

S> Дефрагментация для таблиц в большинстве и не нужно, т.к. обычно организуется список удаленных записей и используются повторно при вставке новой записи, хотя все зависит от организаци, может нужна вся история изменения записей
S> Если у тебя есть ссылочки на файловый GC какой-нибудь OODB буду очень благодарен. Меня это интересует чисто теоретически, для повышения умственного уровня. Нам 1С программистам без этого нельзя.
У меня сейчас с траффиком проблемы. Попробуй погуглить — ключевые слова GemStone Garbage Collector. Где то я видел такую информацию.

С уважением, Gleb.

Здравствуйте, Serginio1, Вы писали:


S> Глеб пойми меня интересует как организовано хранение данных в Объектно-ориентированные БД.
Re[7]: ООСУБД Versant FastObjects и котлеты

Автор: Merle
Дата: 04.03.05