SQL - Cursor

SQL - Cursor (35 Beiträge, 505 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo,

hätte mal eine Frage.

Was machen sogenannte Cursors im Bezug auf SQL Befehle?

Es steht irgendwo, dass man Cursors in Stored Procedures vermeiden sollte.

===>Logik ist Dinge nicht logisch zu betrachten<===

mit OPEN cursor fuehrst du ein SELECT statement durch und mit FETCH Cursor in einer Schleife liest du Row fuer Row ein. Mit CLOSE cursor schliesst du ihn.

is quasi wie ein prepeard statement mit execute wo du dann ein resultset erhaeltst das du verarbeitest.

01.02.2013, 08:29 Uhr - Editiert von *patrick star*, alte Version: hier

Danke!

Ist das dann vergleichbar mit einer Stored procedure? Welche ja einen Ablauf an Statements enthält.

Oder warum nimmt man Cursors?

===>Logik ist Dinge nicht logisch zu betrachten<===

also cursors nimmt man fuers DB2 im cobol und pl1. da gibts nix anderes. das ist einfach die API um SQLS durchzufuehren. zumindest auf der z/os.

eine stored procedure (verwende ich nur als aufrufer, hab aber noch keine geschrieben), sind in der DB abgelegte statements die vom client aus aufgerufen werden kann. quasi anstatt ein SQL statement auszuführen ruft der client eine stored procedure mit parametern auf. die logik und statements liegen in der stored procedure bei der datenbank. stored procedures koennen mittlerweile imo in vielen sprachen geschrieben werden.

Ok, der Sinn von Cursors erschließt sich mir noch nicht ganz.

Was auch noch ein Thema ist, sind die Views? Kennst du dich hier auch aus?

===>Logik ist Dinge nicht logisch zu betrachten<===

zu den CURSOR poste ich dir dann ein Beispiel dann wird es vielleicht klarer.

eine VIEW ist eine logische Sicht auf eine physische Datenbanktabelle.

Das heißt, wenn du z.B. eine Tabelle Kunde hast:

Tabelle Kunde

nummer integer,
vorname char(50),
nachname char(50),
geb_datum date
...

könntest du eine VIEW anlegen die zwar auf die Tabelle Kunde zeigt, aber nur auf die ersten drei Columns.

Somit kannst du manchen Programmen/Aufrufern nur eine eingeschränkte Sicht auf eine Tabelle geben.

Du kannst aber auch alle Columns einer Tabelle in eine View oder auch mehrere Tabellen zu einer View joinen.

Habe auch schon öfter gesehen das es zu jeder Tabelle eine View mit exakt den Columns der Tabelle gibt. Das macht man z.B. für den Fall das wenn die Tabelle erweitert wird, die Programme immer noch die gleiche VIEW haben und nicht geändert werden müssen.

Danke!

Ok, in einer View selbst kann ich aber keine Daten ändern, sondern sie ist nur eine Sicht auf die Tabelle, in der Form, wie ich es festlege, oder?

===>Logik ist Dinge nicht logisch zu betrachten<===

oja, wenn du die rechte hast kannst du daten aendern. sie werden dann natuerlich in wirklichkeit in der tabelle geaendert. aber alle views zeigen dann die geaenderten daten.

Ok, der Sinn von Cursors erschließt sich mir noch nicht ganz.

Der große Vorteil ist, daß du row-by-row arbeiten kannst, und aber immer weißt welche row du gerade bearbeitest.

Ich hab zB. hier eine Schnittstelle zw. SQL und DB2. Die Datenübertragung in die DB2 erfolgt asynchron zur Speicherung ins SQL. Da geh ich per cursor meine Rows durch, übertrag sie in die DB2, und markiere dann meinen Datensatz als übertragen / fehlgeschlagen / bla.

stelle ich mir jetzt ziemlich langsam vor. aber wenns nicht anders geht... (hast du kein etl-werkzeug zur hand?)

cheers
h

stelle ich mir jetzt ziemlich langsam vor

nö

hast du kein etl-werkzeug zur hand?

nö

Eine Stored Procedure kann ebenso external sein und entsprechend externe Lademodule nutzen. Welche dann sogar im Address Space der DB lauffähig sind ... sehr fies.

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

also cursors nimmt man fuers DB2 im cobol und pl1. da gibts nix anderes.

Naja stimmt nicht ganz. Mittlerweile kann man sogar ohne cursor mehrere Sätze auf einmal lesen

08.02.2013, 18:49 Uhr - Editiert von stiefl, alte Version: hier

ein cursor wird üblicherweise in einer stored procedure verwendet, um eine menge von records einzeln (also zeilenweise) zu verarbeiten.
ein cursor wird zuerst deklariert (mit einem select statement, das definiert, welche records im cursor sein sollen), dann geöffnet und dann mit einer schleife (while...) zeile für zeile eingelesen (fetch) und irgendwie bearbeitet (also zb aufaddiert), bis die letzte zeile erreicht ist.

"cursors are for people who don't understand sql" - cursor sind prinzipiell böse

und werden nur von leuten verwendet, die nicht kapiert haben, dass man nie zeilenweise denken soll, sondern immer in spalten, also mit joins und ausdrücken aus ganzen spalten.

der vorige absatz ist natürlich überspitzt formuliert, denn manchmal kommt man um einen cursor nicht herum, zB wenn man eine eigene aggregatfunktion schreiben will, also etwa records nach einer spalte gruppieren und über jede gruppe einen hash bilden.

ach ja, der hauptnachteil ist die katastrophale geschwindigkeit im vergleich zu richtigem

sql.

cheers
h

01.02.2013, 11:08 Uhr - Editiert von hhetl, alte Version: hier

der vorige absatz ist natürlich überspitzt formuliert, denn manchmal kommt man
um einen cursor nicht herum

this

Hmm, nach TSQL Standards sollten Cursors in stored procedures vermieden werden!

Stimmt das? Ist das der Grund warum du gesagt hast, dass Cursors böse sind.

Betreffend Namenskonventionen hätte ich auch noch eine Frage: warum sollten Tabellen nicht mit "tbl" prefix benannt werden?

===>Logik ist Dinge nicht logisch zu betrachten<===

Betreffend Namenskonventionen hätte ich auch noch eine Frage: warum
sollten Tabellen nicht mit "tbl" prefix benannt werden?

.) wozu?
.) was tust du, wenn du eine tabelle durch einen view ersetzen willst

Hmm, nach TSQL Standards sollten Cursors in stored procedures vermieden
werden!

Stimmt das? Ist das der Grund warum du gesagt hast, dass Cursors böse sind.

Ja genau. Meistens sind Cursors eben langsam und unnötig, weil man das selbe Ergebnis mit einem SQL Ausdruck viel besser erreichen kann. Cursors sind oft ein Anzeichen, dass der Programmierer im Geiste noch immer bei Basic hängengeblieben ist und SQL eben nicht richtig verstanden hat.

Aber es gibt wie gesagt auch Ausnahmefälle, die kann der Programmierer im Zweifelsfall aber begründen.

cheers
h

. Cursors sind oft ein Anzeichen, dass der Programmierer im Geiste noch immer
bei Basic hängengeblieben ist und SQL eben nicht richtig verstanden hat.

Dann kläre mich mal bitte auf.

Stellen wir uns eine Datenbankanwendung vor, wo ein Benutzer eine Tabelle mit Daten sieht - zB seine offenen Aufträge. Das könnte ähnlich aussehen wie ein Excel-Spreadsheet. Das sei jetzt optisch so aufgebaut, dass ein Benutzer eine flexible Anzahl an Zeilen sieht... Beispielsweise 40.

Die Inhalte werden natürlich durch SQL am Server generiert...

Angenommen, für den Benutzer Franz gibt es nun 1000 offene Aufträge.
Es gibt nun 3 grobe Ansätze, das zu lösen.

1.) Es wird ein SQL abgesetzt, das alle 1000 Zeilen an den Client zurückliefert. Der kann die dann cachen und stellt halt immer die gerade anzuzeigenden dar. Wenn er den Scrollbar betätigt, kommen halt die nächsten Zeilen aus dem Cache.

2.) Es wird ein SQL abgesetzt, das beispielsweise nur die Zeilen 40-80 aus dem Result darstellt. Wenn er den Scrollbar betätigt, werden die Zeilen 40-80 gecacht und es wird ein neues SQL abgesetzt, das Zeile 81-90 holt. Danach werden Zeilen 50-90 dargestellt.

3.) Es wird ein Cursor aufgebaut. Man holt sich mal die ersten 40 Zeilen ab und stellt sie dar. Wenn der Scrollbar betätigt wird, werden die bekannten Zeilen gecacht und die nächsten Zeile aus dem Cursor geholt. und dann dargestellt.

Kommen wir zu den Vor- und Nachteilen der Lösung:
[1] Immense Netzlast wenn viele parallel zugreifen. Dazu oft sinnloser Aufwand beim Client (Wenn er beispielsweise 3000 Zeilen holt, davon 1-40 darstellt und danach auf etwas anderes geclickt wird)

[2] Aus Sicht vom Netz und Cache am Client weitaus besser: Es wird nur das Benötigte übertragen. Nachteil: Viele SQL-Abfragen werden abgesetzt, dadurch viele Parses ausgelöst (die auf vielen RDBMS nun mal auf nur einem Core laufen, egal wieviele Cores im Server sind), viel I/O um die vielen Querys zu beantworten, ...

[3] Aus meiner Sicht ideal. Die Query wird nur 1x durchgeführt - das ist weitaus sparender am Server als [2]. Aus Sicht des Client ist es einfach zu coden - und ebenso Ressourcensparsam, weil nur das benötigte gelesen wird. Aus Sicht Netz ebenso sparsam.

Warum bin ich im Geiste bei BASIC hängengeblieben? Oder welche Möglichkeit 4 sehe ich nicht?

05.02.2013, 18:41 Uhr - Editiert von kombipaket, alte Version: hier

Schönes Beispiel. Im Hintergrund ändern nun 1000 weitere User/Prozesse die Daten, die gerade in deiner Listbox angezeigt werden. Wie schauts dann aus? In welchem Transaktionskontext befindet sich dein Cursor? Wie geht die DB-Engine mit dem Problem performancemäßig um?

Beurteilung: Basic++

mfg
lukas

Ach wie immer... Du kannst nur rumpflaumen und keine Gegenvorschläge bringen... Und damit du pflaumen kannst, erfindest auch noch Randbedingungen wie "Im Hintergrund ändern nun 1000 weitere User/Prozesse die Daten, die gerade in deiner Listbox angezeigt werden".

Bissale öd. lass es doch.

Der Gegenvorschlag ist einfach sauberes SQL - wo immer das auch geht. Nur so kannst du professionell arbeiten. Alles andere wird irgendwann als Pfusch entlarvt - spätestens wenn die Anwendung ein Erfolg wird und mehr als 100 User am Server saugen.

Ein Freund verdient sich dumm und dämlich damit, Unsauberkeiten - wie die von dir vorgeschlagenen Umsetzungen - nachträglich herauszufinden (oft nach Jahren) und zu beseitigen. Der hat - mit geringfügigen Umgestaltungen - Anwendungen - auf gleicher Hardware - für 1000 concurrent User zum fliegen gebracht, die vorher bei 20 kollabiert sind.

mfg
lukas

Du hast also weiterhin keinen Gegenvorschlag ausser "sauberes SQL" - was immer das konkret bleiben soll.
Du bleibst weiter bei den von DIR erfundenen Zusatzbedingungen (1000 User/Prozesse, die Daten einbuchen, die in meiner Listbox angezeigt werden)

Du willst grundsätzlich nur stänkern - wird mir echt schon zu blöd.

*PLONK*

Lösung 2 - aber vernünftig. Atomare SQL Statements, die die nächsten (bezüglich deiner Sortierbedienung und deines letzten Records) oder vorigen X Records holen und anzeigen. Fertig.

Dadurch hast du keine Transaktionsprobleme und keine Performanceprobleme. Denn SQL Datenbanken sind es gewöhnt, Millionen von SQl Statements auszuführen. Der Glaube, dass du der Datenbank das Leben vereinfachst, indem du einen Cursor öffnest, ist oft falsch. Jeder offene Cursor braucht Resourcen - 1000 User - Autsch... Hingegen kratzen 1000 kleine SQL's keine DB.

mfg
lukas

so sauber kannst du kein SQL programmieren, das du nicht gefahr läufst das eine listbox irgend wann nicht mehr aktuelle werte enthaelt, wenn du nicht alles sperren willst.

Betreffend Namenskonventionen hätte ich auch noch eine Frage: warum sollten
Tabellen nicht mit "tbl" prefix benannt werden?

heißen bei dir variablen im C auch intBlabla und realBloBlo?

Es steht irgendwo, dass man Cursors in Stored Procedures vermeiden sollte.

Ich bin der Meinung, dass Stored Procedures vermieden werden sollten. Aber hier entscheidet ganz klar der Anwendungsfall.

Cursor sind ein Fluch und ein Segen zugleich. Mit einem Cursor kannst dich wie in einer sequentiellen Datei, vorwärts und rückwärts bewegen. Das Cursor nicht performant sind, kommt dann als Argument von Leuten, die auch noch nie was von einem Multi Row Fetch gehört haben.

Vorteil eines Cursor, ganz klar sie sind unheimlich einfach zu erstellen und anzuwenden.

Nachteil, ganz klar, du kannst damit böse Dinge tun ... aber das kannst mit jedem Single Select genauso, wenn nicht gar einfacher.

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

Ich bin der Meinung, dass Stored Procedures vermieden werden sollten.

Jetzt wirds abstrus

Was machen sogenannte Cursors im Bezug auf SQL Befehle?

Im Grunde ist das meiste zu Cursor hier schon erklärt worden:
Ein Cursor "speichert" das Ergebnis einer SQL-Abfrage zur Datensatzweisen Bearbeitung.

Allerdings wüsste ich auf die schnelle nicht, wo man ausserhalb von Stored Procedures Cursor verwendet? Im Sql-Dialog sind Cursor unnötig bzw. nicht möglich.
Die Aussage "Cursor sind Böse" finde ich mal als Schwachsinn. Klar, man kann Cursor schwachsinnig verwenden, da ist das Problem aber vor der Tastatur. Ich verwende regelmäßig Cursor, weil es in unserem Anwendungsgebiet teilweise gar nicht anders (sprich, mit einerm SQL) geht, oder nur wenn man die (Datenbank-)Serverleistung kosteninstensiv erhöht.

emefge
Infosauger
_____________________________________________________________________________

Weil die Lichtgeschwindigkeit höher als die Schallgeschwindigkeit ist, hält man viele Leute für helle Köpfe bis man sie reden hört.

"Bekomme ich bei Ihnen so einen ganz kleinen Lötkolben zum CPU reparieren?"

Wieso Realität? Ich hab doch verdammt noch mal was Besseres zu tun!

>>wo man ausserhalb von Stored Procedures Cursor verwendet? Im Sql-Dialog sind Cursor
>>unnötig bzw. nicht möglich.

in cobol oder pl1 auf dem mainframe sind cursor mehr oder wenig usus.

Allerdings wüsste ich auf die schnelle nicht, wo man ausserhalb von Stored
Procedures Cursor verwendet? Im Sql-Dialog sind Cursor unnötig bzw. nicht
möglich.

http://forum.geizhals.at/t816283,7000004.html#7000004
Ich wüsste eben in vielen Fällen nicht, wie man das ohne Cursor löst (ohne sich dadurch Nachteile einzutreten

)

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung