Мы запускаем версию DB40 .NET в большом клиент-серверном проекте.
Наш опыт показывает, что вы потенциально можете получить гораздо лучшую производительность, чем типичные реляционные базы данных.
Однако вам действительно нужно настроить свои объекты, чтобы получить такую производительность. Например, если у вас есть список, содержащий много объектов, DB4O активирует эти списки медленно. Существует несколько способов обойти эту проблему, например, путем обращения отношения.
Другая боль - это активация. Когда вы извлекаете или удаляете объект из DB4O, по умолчанию он активирует все дерево объектов. Например, загрузка Foo будет загружать Foo.Bar.Baz.Bat и т. Д., Пока не останется ничего для загрузки. Хотя это и хорошо с точки зрения программирования, производительность будет замедляться, чем больше вложений в ваши объекты. Чтобы повысить производительность, вы можете указать DB4O, сколько уровней нужно активировать. Это занимает много времени, если у вас много объектов.
Другой областью боли был поиск текста. Текстовый поиск в DB4O намного, намного медленнее, чем полнотекстовая индексация SQL. (Они прямо скажут вам об этом на своем сайте.) Хорошая новость заключается в том, что легко установить механизм поиска текста поверх DB4O. В нашем проекте мы подключили Lucene.NET для индексирования нужных текстовых полей.
Некоторые API, похоже, не работают, например, API GetField, полезные при применении обновлений базы данных. (Например, вы переименовали свойство и хотите обновить существующие объекты в базе данных, вам нужно использовать эти API-интерфейсы «отражения» для поиска объектов в базе данных. Другие API, такие как атрибут [Index] don ' t работает в стабильной версии 6.4, и вместо этого вы должны указать индексы, используя Configure (). Index ("someField"), который не является строго типизированным.
Мы стали свидетелями снижения производительности вашей базы данных. Сейчас у нас есть база данных объемом 1 ГБ, и все еще происходит быстро, но не так быстро, как когда мы начинали с маленькой базы данных.
Мы обнаружили еще одну проблему, когда Db4O.GetByID закрывает базу данных, если идентификатор больше не существует в базе данных.
Мы обнаружили, что синтаксис Native Query (наиболее естественный, интегрированный в язык синтаксис для запросов) намного, намного медленнее, чем менее дружественные запросы SODA. Поэтому вместо ввода:
// C# syntax for "Find all MyFoos with Bar == 23".
// (Note the Java syntax is more verbose using the Predicate class.)
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23);
Вместо этого приятного кода запроса вам нужен некрасивый запрос SODA, основанный на строках и не строго типизированный.
Для пользователей .NET они недавно представили поставщика LINQ-to-DB4O, который обеспечивает наилучший синтаксис. Однако еще неизвестно, будет ли производительность соответствовать ужасным запросам SODA.
Поддержка DB4O была приличной: мы разговаривали с ними по телефону несколько раз и получили полезную информацию. Их пользовательские форумы почти бесполезны, однако почти все вопросы остаются без ответа. Их отслеживатель ошибок JIRA получает много внимания, поэтому, если у вас есть ноющая ошибка, ее исправление будет часто делаться на JIRA. (У нас было 2 ошибки, которые были исправлены, и еще одна, которая была исправлена наполовину.)
Если все это вас не испугало, позвольте мне сказать, что мы очень довольны DB4O, несмотря на проблемы, с которыми мы столкнулись. Производительность, которую мы получили, сразила некоторые O / RM-фреймворки, которые мы попробовали. Я рекомендую это.
обновление июль 2015 г. Имейте в виду, этот ответ был написан еще в 2008 году. Хотя я ценю положительные отзывы, с тех пор мир изменился, и эта информация, возможно, не так надежна, как тогда было написано.