Мое знакомство с объектно-ориентированными БД несколько дней назад привело к прочтению 150стр документации (за 1 час).
О производительности:
Нашел тесты: db4o в среднем была раза в два медленнее чем MySQL, что является очень хорошим результатом. Например, выборка из 2 миллионов сохраненных на диске объектов занимала 0,1 секунды. При этом db4o работает как в клиент-серверном, так и в embedded режиме и занимает 700кб.
Зачем?
Великолепный Мартин Фаулер в своей книге о построении Enterprise Applications вбивает в читателя одну мысль: нет ничего хуже, чем установка и поддержка объектно-реляционных преобразований. То, что для записи-чтения структуры с двумя полями нужно написать 30 строчек кода (при очень плохом дизайне, при хорошем нужно написать пару классов из 150 строчек) не может не убивать желание использовать реляционные СУБД. Я уже не говорю об отношениях 1..* и *...*.
Как сделать все это с использованием db4o?
db.set(myObject) – записали
//выборка
ObjectSet set = db.query(new Predicate()
{
public boolean match (MyType t)
{
return t.getIntArg() > 4 && t.getStringArg().equals(«Dolphy»);
}
}
Не важно, какие у вас связи 1..1, 1..* или *..*.
Используя паттерны Шлюз Записи Данных (или Шлюз Таблицы Данных) и Фабрика, можно добиться полной независимости от способа хранения объекта в памяти или на диске.
Вам даже не нужно думать об индексах и идентификаторах – БД сама занимается всем этим. И извлекая в двух запросах дважды один объект, она не создаст две копии в памяти, а вернет две ссылки на один объект.
Также нужно отметить, что большинство ООБД реализовано для платформы Java (Встали).
О производительности:
Нашел тесты: db4o в среднем была раза в два медленнее чем MySQL, что является очень хорошим результатом. Например, выборка из 2 миллионов сохраненных на диске объектов занимала 0,1 секунды. При этом db4o работает как в клиент-серверном, так и в embedded режиме и занимает 700кб.
Зачем?
Великолепный Мартин Фаулер в своей книге о построении Enterprise Applications вбивает в читателя одну мысль: нет ничего хуже, чем установка и поддержка объектно-реляционных преобразований. То, что для записи-чтения структуры с двумя полями нужно написать 30 строчек кода (при очень плохом дизайне, при хорошем нужно написать пару классов из 150 строчек) не может не убивать желание использовать реляционные СУБД. Я уже не говорю об отношениях 1..* и *...*.
Как сделать все это с использованием db4o?
db.set(myObject) – записали
//выборка
ObjectSet
{
public boolean match (MyType t)
{
return t.getIntArg() > 4 && t.getStringArg().equals(«Dolphy»);
}
}
Не важно, какие у вас связи 1..1, 1..* или *..*.
Используя паттерны Шлюз Записи Данных (или Шлюз Таблицы Данных) и Фабрика, можно добиться полной независимости от способа хранения объекта в памяти или на диске.
Вам даже не нужно думать об индексах и идентификаторах – БД сама занимается всем этим. И извлекая в двух запросах дважды один объект, она не создаст две копии в памяти, а вернет две ссылки на один объект.
Также нужно отметить, что большинство ООБД реализовано для платформы Java (Встали).


Comments
Наверное, ООБД пойдут лучше.