EJB, JDBC, BigDecimal und atomare Typen

Wie groß sind die Laufzeitkosten von einem BigDecimal gegenüber dem atomaren int?

Wenn ich Integer aus einer Datenbank lesen möchte habe ich mit ResultSet.getInt() das Problem, daß dieser Wert im Falle von null mir eine 0 zurück liefert. In manchen Situationen ist es aber schöner, wenn ich auch in Java mit null arbeiten kann. Dann bin ich bei Beispielanwendungen(EJB) darauf gestoßen, daß dort nur Objekte verwendet wurden(BigDecimal für Zahlen, Date für Datum, usw.). Wie groß ist nun der Performanceverlust von BigDecimal gegenüber einem int?

Wie umgeht ihr dieses Problem, daß Datenbankfelder(Integer) null sein können? Gerade in Hinblick auf EJB's?

Wie groß ist nun der Performanceverlust von BigDecimal gegenüber einem int?

Gigantisch. Aber die gute Nachricht ist: Du brauchst BigDecimal nicht dafür. BigDecimal ist für was ganz anderes gemacht, ebenso wie BigInteger. Wenn du nur nen primitiven Typen als Objekt verwenden willst, dann nimm dazu die passende Wrapper-Klasse.
Es gibt ne Klasse Integer, die du fast wie ein int benutzen kannst (ab Java 5.0, davor ist es umständlicher).
Du verlierst damit auch Performance, aber es ist für normale Fälle verkraftbar.

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Integer.html

Hi Optimizer!

Das Problem ist leider, daß ResultSet für nur den atomaren int zurück gibt. Ist dieses Feld in der Tabelle null, so ist der Rückgabewert 0 und nicht null. Das ist aber ein Problem, da 0 auch ein gültiger Schlüssel sein könnte. Also müsste ich in meiner Anwendung dann auf 0 überprüfen, anstatt auf null. Da müsste es doch eine andere Möglichlkeit geben?

Was für Typen hast du denn zur Auswahl? BigDecimal ist halt madig, weil es nicht mal ne Ganzzahl ist.