Objekt mit verschiedenen Datentypen

[pl4gu33]

hey,...

Problemstellung: Ich bekomme per XML ein Objekt mit mehreren Attributen. Ein Attribut davon kann entweder eine Zahl oder ein String sein. Nun will ich das Ganze in einer Datenbank speichern, wobei ich das Attribut direkt nach dem Erhalten casten will und es als String oder Int speichern will. Nur stehe ich gerade irgendwie auf dem Schlauch, wie ich das am Besten realisiere.

Lösung A (sehr schlecht 😀):
Ich füge in das Objekt ein String UND Int Attribut ein, nur würde das viel zu viel unnötige Werte (null) in der DB geben.

Lösung B : Ich speichere den Datentyp in einer extra Variablen und prüfe jedes mal nach dem Lesen den Datentyp und caste entsprechend.

Lösung C, die ich irgendwie am Besten finde: Ich bau mir eine Basisklasse mit den Attributen, die halt alle gleich sind und erweitere die Klasse mit je 2 Klassen, mit einem String und einem Int Attribut.

Was meint ihr dazu oder habt ihr vll. noch nen ganz anderen Vorschlag 🙂

 

[F.S.WhiTeY]

Deine Erklärung ist ein wenig wirr, wie wird denn das Objekt in der Datenbank gespeichert?

Ich vertshe deine erläuterung nach nur bahnhof.

Im normalfall nimmt man die null werte in der DB in kauf. z.B. könnte eine Entität so aussehen:

BeispielEntity
|ID|--|zahl|--|String|
___________________
|1 |123| null|
|2 |null| blah|
|3 |2| null|

Die Kernfrage ist also: Wie sieht deine Datenbank aus, was willst du abfragen und vor allem wie?!

 

[pl4gu33]

In dem XML gibt es ein Feld <Value></Value> in dem steht halt etwas.
Je nachdem, was dort drin steht, will ich es als Int oder String in dem Objekt speichern. Die restlichen Atitribute sind alle gleich. Also eigentl. genauso, wie dein Beispiel zeigt, nur hab ich mir gedacht, dass es eigentl. nicht Sinn der Sache sein kann, gerade bei vielen Werten, sehr viele Nulls drin zu haben.

Das Speichern der Daten erfolgt per JPA.

Ich hoffe es ist etwas klarer geworden. 😉

 

[F.S.WhiTeY]

Was hälst du von binärdaten? BLOB, CLOB ?

Da kannst du alles drin speichern was du willst solange man Nullen und Einsen daraus machen kann 😉
Das ist die Art wie man Objekte in Datenbanken bringt 😀

EDIT:

Obwohl für einen Integer ein BLOB recht übertrieben ist aber bei BLOB ist es halt wie gesagt egal was da rein geht, man muss nur ein byte-array draus machen.

 

[pl4gu33]

naja das Problem an der ganze Sache ist, dass ich die Daten, wieder auslesen und damit arbeiten muss. Und so muss ich jedes mal gucken, was es wirklich ist, dann kann ichs auch gleich alles als Strings speichern 😉

sry wenn das gerade alles durcheinander is, hab gerade wenig Zeit und muss gleich los, ich versuchs nachher nochmal zu erklären falls es noch Fragen gibt 😀

 

[F.S.WhiTeY]

Das problem liegt ganz wo anders:

Wenn du wissen willst was es ist, String oder Int, hast du zwei Möglichkeiten:

1. Ein Flag setzen, womit du wieder zwei Attribute in der Datenbank hast
2. Rumprobieren und Rumconvertieren, was Rechenzeit und damit Performance zieht.

Deine Idee mit den Unterklassen ist Datenbanktechnisch ein schlechter ansatz, finde ich zumindest.
Klar es würde nullwerte vermeiden aber zwei zusätzliche tabellen erfordern, zu Joins führen und so weiter.

Nullwerte und dazu ein einziges Select-Statement sind da annehmbarer und halten das EER flacher und übersichtlicher.

Das ist zumindest meine Meinung.