Hilfe (dringend) - Wann lieber JDBC anstatt CMP?

[bambi]

Hi Leute,

ich muss ganz dringend wissen, unter welchen Bedingungen ich lieber JDBC verwenden sollten, anstelle eine CMP zu
holen und meine Daten daraus zu lesen.

Es gibt wohl 2 Faelle:

1. Wenn man nur lesenden Zugriff hat und auf dem Ojekt nichts mehr schreiben muss
2. ... HILFEEE...

Bin fuer jede Antwort dankbar!!! *fleh*

 

[Bleiglanz]

was meinst du mit CMP?

Wenn du einen J2EE Server hast, ist CMP immer zu bevorzugen, bevor du tausenmal den gleichen Code schreibst...

Ausnahme: häufige Queries, Batch-Operationen, usw.

 

[bambi]

Wenn du einen J2EE Server hast, ist CMP immer zu bevorzugen, bevor du tausenmal den gleichen Code schreibst...Ausnahme: häufige Queries, Batch-Operationen, usw.

Nicht so ganz. Hab' jetzt die drei Moeglichkeiten gefunden (falls es doch mal wen interessieren sollte :wink: )

1. JDBC ist (meistens) schneller, wenn man einfach nur die Daten lesen will und sie nicht veraendert.

2. Bei komplexen Queries oder beim Verwenden von Funktionen - sowas wie MAX(...) etc. - muss man JDBC verwenden,
da CMP das nicht kann (normalerweise jedenfalls - gibt's Ausnahmen?).

3. CMPs koennen "grosse" Datentypen wie BLOB, CLOB, ... nicht verarbeiten.

 

[Oskar]

3. CMPs koennen "grosse" Datentypen wie BLOB, CLOB, ... nicht verarbeiten.

Also ich behaupte mal JBoss kan damit umgehen. Vorausgesetzt man stellt das mapping fuer den BLOB datentyp richtig im entsprechenden xml config file ein.
Dann kannst du z.B. ein Object auf ein Blob mappen und dann alles reistecken. Sollte funktionieren (ich habs noch nicht ausprobiert).
Gruss
Oskar

 

[Bleiglanz]

Bin fuer jede Antwort dankbar!!! *fleh*
...
Nicht so ganz. Hab' jetzt die drei Moeglichkeiten gefunden (falls es doch mal wen interessieren sollte

Nach deiner lächerlichen Frage ist ein "nicht so ganz" eigentlich eine Frechheit

a) JDBC ist manchmal schnelller und manchmal nicht; wenn du 25 verschiedene Entities hat (mit ca. 10-15 Attributen) dann ist das Schreiben und Testen des entsprechenden SQL Codes auch ein Kostenfaktor beim Entwickeln [von der Robustheit usw. der Anwendung mal abgesehen]

Nimm noch die Transaktionskontrolle dazu und du programmierst dich mit JDBC an die Wand, während du bei CMP nur ein bissl konfigurieren musst...

b) komplexe Joins, komplizierte Aggregatfunktionen sind i.A. mit JDBC einfacher (und performanter) zu bearbeiten (Fast Lane Reader); genauso Batch-Updates...

c) MAX gibts seit J2EE 1.4, schau dir erstmal die EJB QL an

d) natürlich kannst du auch mit CMP Blobs und Clobs verarbeiten, warum soll das nicht gehen? woher hast du das?? manche J2EE Server können sogar beliebige serialisierbare Java Typen in eine binäre DB Spalte "hineinserialisieren"

Fazit: ob man mit JDBC oder CMP arbeiten soll ist eine Frage, auf die es keine allgemeingültige Antwort gibt (zumal ja auch noch die anderen O/R Mapper auf der Matte stehen: Hibernate, JDO, Castor, Toplink...)

 

[farkarich]

Hallo Mal!

Also ich denke mir mal: Java ist Platformunabhängig, EJB-QL auch --> man sollt bei einen bleiben (meist EJB-QL, Entity Beans...) wenn man was entwickelt, weil portiert man die Anwendung dann (von Oracle auf MySQL zb) bringt man sich sonst sicher halb um beim protieren (anderer SQL Dialekt usw), wenn ich nur die EJBs hab, stell ich hald ein anderes Mapping ein, ändere in einer Datei meinen Treiber und danke das wars...

lg