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.
