Arrays persistieren mit JPA

[JanHH]

Hallo,

meine Anwendung macht ziemlich viel Gebrauch von Arrays aus double-Werten, deren Größe stark schwankt (zwischen 10 und 10.000 Einträgen länge). Wie tu ich solche Arrays sinnvoll mit JPA in eine Datenbank?

- jeden double-Wert einzeln (in eine Tabelle mit 1 Wert / Zeile) und dann als collection mappen? Wohl kaum, wg performancee und so?

- binär codiert (halt ein binär-@Lob) mit 64-bit-Blöcken pro Wert, also ein Binär-Objekt pro Array?

- als String, der dann beim Lesen erstmal geparst werden muss? Hat den (für die Anwendung ziemlich grossen) Vorteil, das es menschenlesbar ist?

Was meint ihr?

Gruß+Danke
Jan

 

[Ullenboom]

Am Besten ordentlich, in dem das in eine extra Tabelle kommt. Array ist zwar ein JDBC-Typ, nur ist das bei dem Tripple Datenbanken+Treiber+Mapper eher experimentell.
Schau dir auch mal @ElementCollection an, etwa hier: Mapping and querying a list of primitive types with JPA 2.0 Antonio's Blog.

 

[JanHH]

Was ist denn "ordentlich"? Das Array als Collection mappen (also eine Tabelle mit einem Wert pro Zeile) stell ich mir erheblich suboptimal vor, was die Performance angeht. Eine Lösung, wo das ganze Array ein einziger Eintrag in der Datenbank ist, kommt mir besser vor.

Danke für den Link, gleich mal anschauen.

 

[Ullenboom]

Klar, kann man das auch verpacken und ist sicherlich auch für einige Anwendungsfälle gut. Allerdings sehe ich das so: Ein Array ist eine Collection wie jede andere auch. Warum soll die Datenbank das nicht optimal bearbeiten können über die herkömmliche Schlüssel-Beziehung? Das ganze Umcodieren ist auch nicht umsonst. Wenn du 10.000 Elemente hast, und da kommst ein Element dazu/weg ist das auch Arbeit: alles auspacken (parsen, konvertieren), ändern, neu verpacken. Zudem ist das Ganze von der DB nicht mehr einfach durchsuchbar, aggregierbar, ... du endet mit einer fetter LOB-Spalte. Aber wenn die Elemente im Prinzip nur write-once sind, warum nicht.
Was nicht so chic bei meiner Lösung ist, dass ein Array als Liste eine Reihenfolge hat, die Einträge in einer Datenbank aber nicht. Hier braucht man also noch eine Spalte.
Die DB hat mit so vielen Einträgen keine Probleme. Naja, kommt auf die DB an Sonst heißt die übliche Empfehlung: Nimm den einfachsten Weg wie möglich, und optimiere dann, wenn die Performance klemmt.
Alternativ und simpel: nimm eine serialisierbare Klasse (DoubleValues), die deine doubles speichert:

@Lob
public DoubleValues getDoubleValues() {
return array;
}

So musst du dich nicht selbst um das Verpacken kümmern.

 

[e86wbdw8ew]

[...] (also eine Tabelle mit einem Wert pro Zeile) stell ich mir erheblich suboptimal vor, was die Performance angeht.[...]

Das ist es auch, zumindest in meinem Fall. Folgendes Beispiel, es gab mal eine Anforderung Zeilen bestehend aus einer festen Anzahl und variablen Anzahl von Werten in einer JTable anzuzeigen. Die variablen Inhalte wurden auch eine Zeile pro Wert gespeichert, das war so unglaublich langsam ab einer mittel/höheren 5-stelligen Anzahl anzuzeigender Zeilen. Da sich die variablen Inhalte so im Bereich 50-150 Werten bewegen, werden die nun in einer Spalte, in ihrer Gesamtheit als String gespeichert und für die Anzeige rausgeparst. Seither gibt es keine Probleme mehr.

 

[Ullenboom]

Einen Zusammenhang zwischen Datenbank-Tabellen und JTable-Tabellen sehe ich nicht.

 

[maki]

Das ist es auch, zumindest in meinem Fall. Folgendes Beispiel, es gab mal eine Anforderung Zeilen bestehend aus einer festen Anzahl und variablen Anzahl von Werten in einer JTable anzuzeigen. Die variablen Inhalte wurden auch eine Zeile pro Wert gespeichert, das war so unglaublich langsam ab einer mittel/höheren 5-stelligen Anzahl anzuzeigender Zeilen. Da sich die variablen Inhalte so im Bereich 50-150 Werten bewegen, werden die nun in einer Spalte, in ihrer Gesamtheit als String gespeichert und für die Anzeige rausgeparst. Seither gibt es keine Probleme mehr.

Wer liest denn bitte eine Tabelle mit 10000+ Einträgen?
Paging wäre da vielleicht eine Alternative.

Habe auch schon DropDown Boxen mit über 10000 Einträgen gesehen, imho stimmt dann was an der UI nicht

 

[e86wbdw8ew]

Einen Zusammenhang zwischen Datenbank-Tabellen und JTable-Tabellen sehe ich nicht.

Dann ersetze die Textstelle "...Anzahl von Werten in einer JTable anzuzeigen...." mit "... Anzahl von Werten aus einer relationalen Datenbank in einer JTable anzuzeigen..."

 

[e86wbdw8ew]

Wer liest denn bitte eine Tabelle mit 10000+ Einträgen?
Paging wäre da vielleicht eine Alternative.

Ach das geht schon wir hatten da schon 200k+ Einträge in der Anzeige. Aber Kunden mit so vielen Daten exportieren das sowieso gleich. Aber einer hat eben mal, vll. aus Neugier, die Anzeige gewählt und angemerkt das es etwas schnarchig läuft. Und als Ergebnis kam eben heraus, dass das Zusammensuchen der variablen Anteile so lange dauert. Uns seit der Anpassung geht es sehr flott.

 

[JanHH]

Ich denke, das codieren/decodieren (entweder als String oder binär-Objekt) kostet kaum Performance. Den Kram aus tausenden Zeilen einer DB-Tabelle zusammenzusuchen, schon (vermute ich mal so).