hallo
das ist nun mal so, wie relationale datenbanken funktionieren - und so, wie fast alle db-zugriffssysteme.
stell dir vor, dein select liefert 20000 datensätze. und nun stell dir vor, jdbc würde zuerst alle 20000 datensätze in den hauptspeicher einlesen und dir dann eine collection darauf geben. dein programm wäre a) saulangsam und b) nur auf üppig mit hauptspeicher ausgerüsteten rechnern lauffähig. abgesehen davon - vielleicht kommst du schon beim dritten datensatz darauf, dass du eigentlich schon mit dem lesen aufhören kannst und du den rest der daten nicht brauchst.
jdbc geht daher den einzig sinnvollen weg: wenn du dein statement absetzt, wird das statement in der db erst mal geparsed (so eine art precompiler). technisch baust du im db-system einen sogenannten cursor auf - also ein temporäres konstrukt, mit dem du durch das suchergebnis navigierst. die struktur dieses cursors ist im resultset abgebildet.
beim ersten zugriff auf den cursor wird das statement tatsächlich ausgeführt und der erste datensatz der ergebnismenge geliefert. intern baut die db vermutlich einen buffer auf, liest also blockweise (oracle z.b. standardmässig 10 zeilen auf einmal - kann aber konfiguriert werden).
dein resultset kann nun zeilenweise über den cursor auf das ergebnis zugreifen. was du vom ergebnis aufheben willst, ist rein deine angelegtenheit.
dieses vorgehen ist z.b. recht praktisch, wenn man wissen will, ob es irgendeinene datensatz gibt, der den anforderungen entspricht - aber egal wieviele. bei einem „select count(*)“ müsste die db ALLE Zeilen in der db zählen - was schlimmstenfalls einen fulltablescan bedeutet und entsprechend zeit dauert. ein „select *“ und abbrechen nach dem ersten datensatz kann hingegen recht flott sein.
hätte jdbc aber das gesamte ergebnis beim ersten zugriff geladen, hättest du keine chance zum ausnutzen dieser optimierung.
wenn du es komfortabler haben willst, kannst du ja ein paar wrapper-objekte schreiben, die dir genau das machen - also das gesamte ergebnis laden und als collection zur verfügung stellen. ist sogar relativ einfach, sowas allgemeingültig zu definieren. aber wie gesagt - bei grossen datenmengen ist das eine extrem unpraktische vorgehensweise. und jdbc orientiert sich nun mal nicht an spezielle sonderfälle (datenbanken mit max 10 einträgen) sondern an „echten“ problemstellungen (datenbanken mit mehreren millionen einträgen).
lg
erwin
