Objekt-orienterte databaser (del2): Db4objects
- Friday, February 27th, 2009
- Skriv en kommentar
Del 1 i denne serien finner du her.
De første objekt-orienterte databasene kom ut av forskningsmiljøene tidlig på 70-tallet, men begrepet ble ikke tatt i bruk før 1985. På 90-tallet dukket det opp mange, komersielle løsninger, hvor objektdatabaser bl.a. ble integrert i programmeringsspråk for persistering av objekter. C++ var lenge størst på dette området.
Rundt 2004 fikk objektdatabaser en ny vekst gjennom diverse open source-prosjekter. Det finnes i dag et hav av løsninger under diverse lisenser og for diverse programmeringspråk.
Objektdatabasene har hatt liten effekt på mainstream, kommersiell dataprosessering, og mange utviklere vet derfor lite om dem. Men ODBMS er mye brukt innenfor enkelte spesialfelt, som f.eks. telekommunikasjon, fysikk og molekylærbiologi. Det er verdt å merke seg at verdens største database er en objektdatabase: Stanford Linear Accelerator Center’s ODBMS var den første databasen over 1000 terabytes. Objektdatabaser er også attraktive for embedded devices og innefor real-time systemer.
Den objektdatabase-teknologien jeg har valgt å eksperimentere med heter db4o (database for objects). Db4o er en objektdatabase både for Java og .NET, og er gratis for ikke-kommerisell bruk. Produktet fikk prisen Best of Open Source Developer Tools i 2008, og har et stort community. Det finnes allerede et hav av open source sideprosjekter som implementerer støtteverktøy og lignende ting – intergasjon til Castle, Spring.NET og CSLA, støtte for bruk i Ruby, JRuby, Eiffel.NET, Scala og PHP, Ant tasks, Silverlight-støtte, ASP.NET providers osv. Dokumentasjonen er relativt bra, og teknologien er i produksjon mange steder: bl.a. sitter det en db4o-database i hjertet av Spanias nye kontrollsenter for høyhastighetståg.
Databasespørringer i db4o
I del 1 viste jeg hvor enkelt det er å lagre objekter i objektdatabasen. Oppdatering av objekter er like enkelt – man bruker den samme Store() metoden faktisk – den legger inn nye objekter og oppdaterer eksisterende objekter. Når det gjelder å hente ut data har db4o flere muligheter.
For det første kan man bruke QueryByExample (QBE). Dette er noe f.eks. NHibernate også støtter. Man oppretter et nytt objekt av den typen man skal hente ut – ofte kalt en prototype – og setter properties som man er interessert i å matche på. Vil man f.eks. hente ut alle Personer som heter “Torbjørn”, oppretter man en person som heter nettopp Torbjørn og sender det til QBE metoden:
public IEnumerable<Person> FindAllTorbjorns()
{
using (IObjectContainer db = Db4oFactory.OpenFile(“foo.db”))
{
Person prototype = new Person
{
GivenName = “Torbjørn”
};
return db.QueryByExample(prototype).Cast<Person>();
}
}
QBE kan selvsagt ikke brukes til alt, men det er overraskende kraftig, og godt nok i mange tilfeller.
Den neste muligheten i db4o er det de kaller native queries. Her bruker man elementer i programmeringspåket man jobber i til å gjøre spørringer mot objektene. Man bruker typisk delegater / anonyme metoder til å definere kriterier for hvilke objekter som skal returneres. En variant av native queries i .NET er db4o’s støtte for LINQ. Jeg er veldig glad i LINQ, og synes det er den mest naturlige måten å jobbe med databasen på. Skal jeg f.eks. hente ut alle personer som har enter en shipping-adresse eller en e-post adresse (ja, jeg har utvidet domenemodellene min litt nå), så kan jeg gjøre det slik:
public IList<Person> FindPersonsWeCanContact()
{
using (IObjectContainer db = Db4oFactory.OpenFile(“foo.db”))
{
var query = from Person p in db
where p.ShippingAddress != null
|| p.Email != null
select p;
return query.ToList();
}
}
Gjennom LINQ kan jeg uttrykke akkurat hva jeg er ute etter. Jeg kan jobbe med databasen som om det var en avansert kolleksjon i minnet, og få tilbake mine egne domeneobjekter uten å måtte gjøre noen form for mapping. Å jobbe med persistert data har aldri vært enklere!
Det finnes selvsagt noen detaljer jeg har utelatt. F.eks. vil ikke db4o returnere den komplette objektstrukturen (Person + alle underobjekter) uten at jeg eksplisitt ber den om det. Db4o kan derimot konfigureres til f.eks. å bruke eager fetching / load all levels hver gang jeg henter ut personobjekter – eller jeg kan definere nøyakig hvor mange nivåer som skal lastes. Samme teknikk må man bruke når man oppdaterer og sletter – fortelle db4o hvor mange nivåer som skal påvirkes.
Det finnes også en siste måte å gjøre spørringer, og det er via db4o’s SODA Query API. Dette er den mest kraftige måten å gjøre spørringer på, men også mer low level, og krever at man setter seg inn i API’et. Foreløpig har jeg ikke hatt behov for det – LINQ har gitt meg alt jeg trenger til nå, og er den måten dokumentasjonen anbefaler å bruke – men om du vil lære mer har db4o documentert SODA ganske bra også.
Dette er andre del av en artikkelserie om objekt-orienterte databaser, basert på mitt NNUG-foredrag om samme tema. Fortsettelsen følger..
Kategorier: O/RM & databaser.
RSS feed for kommentarene.
Tilbaketråkk.
March 21st, 2009 at 11:57 pm
Foredraget ditt om dette var så inspirerende at jeg bare måtte prøve litt.
Det som jeg synes var hææærlig var at arv bare funker ut av boksen.
Jeg har to classer i testen min: Person, og Spiller.
Person har propertiene Fornavn, Etternavn osv.
Spiller(fotballspiller) arver fra Person, og har propertier som draktnummer osv.
Når jeg legger inn Spillere i databasen så dukker de opp både som spillere og som personer
… er ikke det hææærlig?
Man kan virkelig jobbe DDD med dette her. De fleste gidder ikke bruke arv, for man må ha diskriminatorkolonner osv når man skal persistere. Her går det som en lek
March 22nd, 2009 at 12:31 am
Nice entries on db4o! Thanks a lot for your blog posts =D
I see that you use twitter, you can follow us here:
http://twitter.com/db4objects
Best!!!
German
March 22nd, 2009 at 12:46 am
Kjekt å høre at du eksperimenterer.., og liker det. Gleder meg til å høre mer om hva du får til med objektdatabaser. Kanskje du kan holde et oppfølgingsforedrag senere – når du har fått mer erfaring enn det jeg hadde?!
July 11th, 2009 at 12:17 pm
Har du brukt det i noen prosjekter enda? Da ville det vært interessant å høre dine erfaringer.
Jeg har brukt alternativer til relasjonsdatabaser tidligere, og har også eksperimentert med db4o tidligere, og likte det… Men det har lissom ikke tatt helt av enda…
July 11th, 2009 at 3:10 pm
Hei Arjan.
Eneste stedet jeg har db4o \”i produksjon\” er i Contiki\’s interne personellstatus-tjeneste, og der lagrer jeg bare ett type objekt (og ikke flere av dem enn det er ansatte i CMA Contiki), så det er ikke så mye å skryte av. Jeg laget mer komplekse ting da jeg eksperimenterte med teknologien, men jeg trenger altså fortsatt erfaring med større systemer som faktisk skal brukes til noe.
Oppdatering: Faktisk ett sted til jeg har det i prod, og det er i Contiki\’s exception-database – en logg over alle runtime exceptions og tilsvarende som har oppstått i produktet vårt, med tilhørende årsak/løsningsforslag. Dette brukes i supportsammenheng og under installasjon/utrulling av nye systemer. Men også her er det ikke spesielt kompliserte strukturer eller mye data: ContikiException