Использование объектно-ориентированной базы данных (db4o) для приложения среднего масштаба

Question

Я столкнулся с db4o базой данных OODB и задаюсь вопросом, как она сравнивается с традиционным стеком с RDBMS или ORM, например Hibernate/EclipseLink. Приложение представляет собой систему документооборота и со временем расширяется. Не уверен, что OODB, как db4o, подходит хорошо. Я никогда не работал над OODB, поэтому не могу сказать. Любые предложения?

Answer 1

Hi! Вот некоторая информация, основанная на моем собственном опыте с DB4O.

В наши дни существует много вариантов для так называемых OODB (объектно-ориентированных баз данных). Вместо того, чтобы писать список подобных решений, я могу рассказать вам, как это работает, а не использовать регулярную СУБД, потому что это был ваш реальный вопрос.

Вы можете прочитать довольно хорошее сравнение некоторых из наиболее часто используемых систем более в Википедии: Comparison of OODB's

Если вы используете ORM упорную methology с помощью инструмента, как NHibernate, вы даете себе легкое время, когда он приходит к запросам и обновлению базы данных за сохраненными объектами. Вы можете придумать такой инструмент, как NHibernate, как «гибридное» решение, в то время как с чистыми объектно-ориентированными базами данных, такими как вы упомянули (один из которых я сделал с собой) DB4O от Versant/Actian, вы можете работать напрямую с файл в файловой системе или выбрать подходящее решение Client/Server. DB4O поддерживает оба.

Наиболее распространенным сценарием, вероятно, был бы упомянутый выше сценарий, в котором вы бы использовали файл в локальной системе, чтобы сохранить сохраненные копии объектов вашего приложения.

DB4O теперь существует как бесплатный для некоммерческого использования продукт и имеет как Java, так и версию .Net. Они оба работают одинаково, и из моего личного опыта они работают очень хорошо для чего угодно: от простых 2-10 мегабайтных баз данных до файлов весом около 10-12 ГБ.

Как правило, по мнению разработчиков DB4O, если вы ожидаете, что база данных вашего приложения должна быть больше, чем около 15-16 GigaBytes, вы должны рассмотреть другие подходы.

DB4O однопоточный, и для этого требуется довольно быстрое процессорное ядро ​​для обработки большого количества транзакций. Но ему удается хорошо работать, учитывая это очевидное ограничение.

DB4O легко расширять и должен охватывать большинство потребностей в объектно-ориентированной базе данных.

Вот небольшой пример, который показывает, насколько легко для подключения и написать ряд пользовательских объектов в БД, взятые из одного из моих собственных проектов: (DBPATH это строковая константа)

public static void StoreObjectsToDb(IEnumerable<SyncObject> syncObjects) 
    { 
    using (IObjectContainer container = Db4oEmbedded.OpenFile(DbPath)) 
    { 
     try 
     { 
      foreach (var hdSyncObject in syncObjects) 
      { 
       container.Store(hdSyncObject); 
       Console.WriteLine("Stored Object with HdID {0}\t<-->\tTfsID {1} to database.",hdSyncObject.HdId,hdSyncObject.HdTfsNo); 
      } 
      container.Commit(); 
      LogUtility.WriteToLog("Successfully wrote all objects to database."); 
     } 
     catch (Exception ex) 
     { 
      container.Rollback(); 
      LogUtility.WriteToLog("Could not save objects to database. Rolling back changes...\nError: {0}",ex.Message); 
     } 
     finally 
     { 
      container.Close(); 
     } 
    } 
    } 

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

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

Надеюсь, что это немного облегчит ситуацию.

Chris