Embedded ORM DB

[Zed]

Hallo,

Ich beschäftige mich zur Zeit mit einer GUI Anwendung mit der ich meine Mp3 verwalten kann.
Ich besitze ca.1800 Mp3 und das einlesen in MP3File Objecte dauert knappe 4 Minuten. Also fällt arbeiten nur mit dem Filesystem flach.

Was ich mir überlegt habe ist die Anwendung duch eine Datenbank zu unterstützen um schnell die Mp3 zu suchen oder zu filtern. In Frage kommt eingentlich nur eine embedded Datenbank.

Ich wollte eigentlich DerbyDB nutzen. Was mir gerade in den Sinn gekommen ist wäre es nicht evtl. besser ein ORM Datenbank zu verwenden. Nur habe ich leider keine Erfahrung mit solchen Datenbanken. Gibt es eine Java embedded ORM DB?


Meine Idee der Umsetzung:
Ich habe vor das ganze in meheren Tabellen zu realsieren album, song, genre. Song enthält den primären Schlüssel von album und genre. So kann ich einfach alle songs filtern die in dem Album vorkommen oder das genre besitzen.

Könnte ich das Object Mp3File in Songs ablegen und die Tabelen album u. genre als normale Tabellen bei einer ORDB behalten? Ich denke wenn ich nur eine Tabelle mit Mp3File Objekten besitze muss ich immer alle Objecte aus der DB hollen und mit Album und Genre beim filtern vergleichen. Das würde sich bei großen Mengen äußerst negativ auf die Geschwindigkeit auswirken.


Wäre für ein paar Ratschläge dankbar. Will nicht sinnlos meine Zeit verschwenden.


Gruß
z

 

[HoaX]

Ich würde dir da Hibernate/TopLink/... ans Herz legen

 

[Zed]

Hab mich gerade bisschen mit Hibernate beschäftig und anscheinend funktioniert das mit Derby.

Was ich beim lesen erfahren habe ist das ich eine Maping Datei erstellen muss. Welchen Vorteil soll das den bringen? Ich könnte mir doch eine DAO erstellen die mir die Arbeit beim schreiben und lesen von der DB abnimmt.

Die Methode mit dem ORM kamm mir nur in den Sinn da meine MP3 etliche ID3v2 Tags besitzen und die in einer Dao zu erfassen eine riesen Fleisaufgabe ist.

 

[maki]

Mit JPA (Hibernate/Toplink) brauchst du keine Mappingfiles mehr, sondern Annotations.

DAO != ORM

 

[foobar]

Mir ORM Datenbank meinst du bestimmt sowas:
http://www.db4o.com/

Da brauchste keine zusätzliche ORM-APi, weil die DB schon objektorientiert arbeitet.

Ich könnte mir doch eine DAO erstellen die mir die Arbeit beim schreiben und lesen von der DB abnimmt.

Am einfachsten gehts so: http://www.hibernate.org/328.html

Die Methode mit dem ORM kamm mir nur in den Sinn da meine MP3 etliche ID3v2 Tags besitzen und die in einer Dao zu erfassen eine riesen Fleisaufgabe ist.

Die ID3-Tags gehören aber als Property in deine Entity und nicht ins DAO. Das DAO dient nur zum Zugriff auf Hibernate und kappselt Queries.

 

[Gast]

Ein ORMapper ist dazu da die Verbindung zwischen Objekten und Datenbank zu realisieren.

Um zu Definieren wie diese Verbindung genau aussehen soll, kann man das in Mappingdateien definieren.

Möglichkeit 2 ist Objekte mit Annotations zu versehen und den ORMapper daraus die DB generieren zu lassen (Java Persistence Api).

Daraus folgt:
OBJEKT === ORMAPPER === Datenbank

Ein DAO setzt IMHO zwischen Objekten und ORmapper an. Also:

OBJEKT === DAO ===ORMAPPER === Datenbank

 

[Zed]

Ich hab gerade diesen Satz im Netz gefunden:

Hibernate Annotations do not work because Derby does not allow a unique column to be nullable. Version: hibernate-3.1beta1 and hibernate-annotations-3.1beta4



Ich glaube ich werde es erstmal mit dem ORM lassen und mich auf ID3v1 Tag konzentrieren und wenn man die Application einigermassen läuft evtl. das ganze erweitern. Die Einarbeitung in Hibernate und co werde ich mal zurückstellen.