On Sat, 1 Jun 2002 18:16:56 +0200, "Jay Jay" <c_j@adslhome.dk> wrote:
>Hejsa...
>
>Jeg mener ikke der er blevet lavet nogen OO db. Kun i princippet. Men hvis
>der er nogen som kender en, så må du undskylde.
Vi undskylder dig; der er lavet adskillige, Objectivity, Versant,
Poet, Ja, tag et kig på flg. link for en større liste:
http://www.well.com/user/ritchie/mini-faq.html
En god resource er også nyhedsgruppen comp.databases.object.
Men tilbage til subject; Jeg har haft lejlighed til at eksperimentere
med Objectivity, og generelt kan jeg sige at det er en drøm at arbejde
med en oodbms, hvad angår OO til ER mapning - der er nemlig ingen.
Det er en kommerciel DB, men der findes, svjh. en gratis java demo som
man kan bruge til at afprøve den.
Et par af de erfaringer jeg lærte da jeg brugt denne:
Objectivity lagrer objekter på 'pages', og ikke i tabeller (som i
RDBMS) Fidusen er at relaterede objekter lagres på samme page, f.eks.
en person og hans adresse lagres samme, så når en page loades, så er
der stor sandsynlighed for at relaterede objekter loades med.
Alle objekter har et objekt id (OID), så er en 64 bits kode (de
snakker om at udvide den til 128 bit), som er opdelt i flg:
16 til database ID
16 til container ID
1 som jeg ikke lige kan huske hvad blev brugt til
15 til pages
16 til slots på en page
Alle 2^16 databaser kaldes en federated db.
Det betyder at et OID faktisk er en logisk adresse på en fysisk
placering, idet en database er en fil på en disk (på en _vilkårlig_
server!) - så nar man accesser et object så ved DB'en hvor det skal
hente det med det samme. Ulempen er at man kan ikke flytte et object
fra et sted til et andet, uden at man skal rette alle referencer til
OID'et fra andre objekter, fordelen er indlysende idet at databasen
ved hvor objektet er uden videre.
En spøjs ting er at der låses på container niveau, dvs. at man låser
faktisk 2^31 objekter i et go; det lyder vildt, men når man nu ved at
alle relaterede objekter ligger sammen, så bliver de låst på samme
tid. Objectivity har 'kun' to processer en lockserver og en
pageserver; pageserveren loader og saver de pages der requestes, og
lockserveren står for at låse containers. Der bor en pageserver på
hver fysiske maskine, mens der kun er een locksercer totalt - der er
to ulemper ved dette; dels kan det være en flaskehals, men når man
tænker på niveauet der låses på, kan man se at dette ikke er et
problem, og dels at hvis den server som LS kører på bliver cuttet fra
netværket, så dør federation DB'en - det er dog i så fald umiddelbart
muligt at flytte LS processen til en anden vilkårlig backup server
uden problemer.
Det er så op til designeren af databasen at lave en 'storage' strategi
som fordeler objekter over forskellige containere for at minimere
konflikter. Det svarer _:lidt_ til at lave index, men igen, når denne
strategi er lagt, kan man ikke lave den om på de eksisterende
objekter. F.eks. kan en strategi være at systemet er nomineret til
5000 samtidige brugere der arbejder på personer på samme tid, så vil
man f.eks. fordeler personer over 10000 containere ved f.eks. at bruge
hashcode på person navn modulus 10000 for at finde container id hvor
en ny person skal oprettes i.
Når man normalt accesser objekter i en oodb laver man en collection
(som også består af objekter i databasen), f.eks. et sorteret træ af
en slags. Noderne i dette træ fordeles over forskellige containere for
at minimere konflikter når træet opdateres.
Sådant et træ definere man så som 'rod' objekt i db'en, så for at
finde en person's adresse vil noget java kode se sådan ud (ca.)
session.start(); // new transaction
ooFDB fdb = ooFDB.getFdb(); // get federated db
Tree tree = fdb.getRoot("Persons");
Person person = tree.lookUp("Hans Hansen");
Address address = person.getAddress();
:
:
session.commit();
Ulempen ved et sådant' et træ er at man manuelt selv skal indsætte sit
objekt, men så indsætter du også hele din objekt graf for dit objekt:
Person p = new Person();
p.setAddress( new Address());
tree.insert(p); // Da tree er persisteret bliver p automatisk
persisteret
//adressen bliver automatisk taget med nå p
bliver persisteret
Fordelen her er at de er afsindigt hurtige til at finde objekter frem
(pga. OID'et), og der er også hurtige til at gemme objekter (relateret
til en RDB).
Den kan også lave normale typer index, men kun på simple typer :-/ Jeg
hørte at andre oodb'er kan lave index på metode retur værdier (det kan
du selvfølgeligt også i objectivity, men kun i et collection object,
ikke som indbyggede index).
Generelt er oodbms meget interessante, men de har det problem at de
'slås' mod relatins databaser, som har været på banen i mere end 30
år, og derfor er meget mere modne, har stærkere værktøjer og ikke
mindst en kæmpe bruger og udvikler base; det ser dog ud til at de
vinder markedsandele stille og roligt. Dog er der for java's
vedkommende kommet en stærk konkurrent, nemlig EJB, som muligvis vil
forsinke oodbms'ers gennembrud betragteligt (jeg tror dog at EJB
kombineret med en oodb er en kolonorm stærk kombination, jeg mangler
dog at sen en ejb applikations server som kører på en oodb; ejb er
desværre primært designet til at bo oven på en rdb).
Ok, det var lidt om objectivity (jeg lyder lidt som en sælger), se her
for flere detaljer:
http://www.objectivity.com, Som en lille
afslutnings bemærkning kan jeg fortælle at objectivity bruges i
Iridium (motoralas satelit mobil telefon system), og f.eks. hos CERN
til at opsamle data for deres partikel accelerator.
vh. ld
p.s. Mit firma forkastede desværre Objectivity af konservative årsager
(ikke et markedsførende produkt).
>Hilsen
>Mig
>
>
>-------------------------------------------------------
>"Morten Olsson" <molsson@vip.cybercity.dk> skrev i en meddelelse
>news:ada2rn$14bf$1@news.cybercity.dk...
>> Hej folkens,
>>
>> jeg vil som et lille fritidsprojekt pille lidt med objektorienterede
>> databaser og java. Er der nogen af jer der kan anbefale et oo dbms der er
>> gratis, og rimelig let at integrere med java ?
>>
>> på forhånd tak
>>
>> mvh.
>>
>> Morten Olsson
>>
>>
>