Alternative zu LIMIT/SAMPLE in SQL / ODBC
-
Moin,
Ich frage mich gerade ob ich in Standard SQL die
Anzahl von Datensätzen die ich zurückbekomme im Resultset
limitieren kann, wie es auf MySQL mit LIMIT geht.
Leider kann ja nicht jede DB LIMIT, Teradata nutzt z.b. dafür SAMPLE.
Kann man dies evtl. auch per ODBC einschränken ?Devil
-
IMHO ist LIMIT im Standard drin.
MySQL unterstützt auch noch einen erweitereten LIMIT . LIMIT beginne ab,anzahl
-
Es wird aber nicht von allen DBs unterstützt, z.b. kann imho Sybase dies nicht.
Gibts ne Möglichkeit es über ODBC einzuschränken ?
-
Es gibt im OCBC-API die Funktion SQLSetStmtAttr().
Dort kann man mit dem Attribut SQL_ATTR_MAX_ROWS die Anzahl der zu liefernden Datensätze einschränken.
-
Das macht aber bei Datenbanken die es nicht kenne keine Sinn.
LIMIT hat den Sinn das nicht alle Daten vom Server geliefert werden bzw. er einfach bei selektieren aufhört und somit schnell ist.Man kann aber aus der Ergebnismenge immer ein LIMIT machen. Einfach nicht alle Daten verarbeiten. Sie werden aber trotzdem von Server gesendet.
Läßt sich aber auch durch ein Sinnvolleres SQL-Statement durchführen.Will ich in den ersten Datensat aus einer Tabelle macht ein
SELECT * from Table
keine Sinn.
SELECT * from Table where ID = 1
ist richtiger wenn man ein Autoinc primärschlüssel hat.
-
frenki schrieb:
Es gibt im OCBC-API die Funktion SQLSetStmtAttr().
Dort kann man mit dem Attribut SQL_ATTR_MAX_ROWS die Anzahl der zu liefernden Datensätze einschränken.
Das wars
Da ich eh über ODBC gehe, ist das wohl die sinnvollste Lösung...Devil
-
Unix-Tom schrieb:
Das macht aber bei Datenbanken die es nicht kenne keine Sinn.
LIMIT hat den Sinn das nicht alle Daten vom Server geliefert werden bzw. er einfach bei selektieren aufhört und somit schnell ist.Man kann aber aus der Ergebnismenge immer ein LIMIT machen. Einfach nicht alle Daten verarbeiten. Sie werden aber trotzdem von Server gesendet.
Läßt sich aber auch durch ein Sinnvolleres SQL-Statement durchführen.Will ich in den ersten Datensat aus einer Tabelle macht ein
SELECT * from Table
keine Sinn.
SELECT * from Table where ID = 1
ist richtiger wenn man ein Autoinc primärschlüssel hat.Nein, das hast du falsch verstanden. Die Aufgabe von ODBC ist es, die Unterschiede der verschiedenen Datenbanken unter einen Hut zu bringen. Wenn der ODBC-Treiber für deine DB vernünftig implementiert ist, wird er bei MySql ein LIMIT N an das Statement anhängen. Bei DB2 ein FETCH FIRST n ROWS ONLY, bei MS SQL ebenfalls ein TOP N bei Teradata (nie gehört...) ein SAMPLE usw.
Es macht also keinen Unterschied, ob du das über's ODBC-API machst, oder direkt per SQL-Statement. Der Vorteil ist halt, dass man sich nicht um die drunterliegende Datenbank kümmern muss. Vorausgesetzt natürlich immer, das der ODBC-Treiber was taugt.
Edit: Ist natürlich klar, dass es keinen Vorteil bringt, wenn die DB keine Möglichkeit für ein LIMIT oder etwas in der Art anbietet. Aber auch bei denen kann man ja das Glück haben, dass der ODBC-Treiber das z.B. regelt, indem er einfach einen Cursor benutzt und die Rowset-Size auf die benötigte Datensatz-Anzahl setzt, um so den Netzwerktraffic zu vermindern.
-
Ich habe da nichts falsch verstanden.
Das macht aber bei Datenbanken die es nicht kenne keine Sinn
Mein Aussage ist: Man sollte nicht auf Hilfen wie LIMIT zurückgreifen wenn man sein RDBMS nicht kennt sondern gleich ordentlich implementieren, sodaß LIMIT nicht notwendig ist.
Wenn man ODBC verwendet und in seinem CODE LIMIT verwendet dann möchte man auch nur die Anzahl Datensätze. ODBC verwendet man aber nicht weil es einfach oder schwierig ist, von MS kommt oder was auch immer. Man verwendet es um sie das RDBMS offen zu halten.Jemand der sowieso nur z.B. MySQL,Postgre, etc. verwendet greift auf die API zurück da diese um längen schneller ist als ODBC.
-
Hmm, Sorry, ich hatte dich so verstanden dass du meintest, der ODBC-Weg würde trotzdem das komplette Resultset schicken, dem wollte ich widersprechen
Und ich würde nicht sagen, dass man das DB-API vorziehen sollte. ODBC lernt man einmal und kann künftig jede beliebige Datenbank programmieren, ohne ein neues API lernen zu müssen. Ich würde ODBC nur dann nicht verwenden, wenn der ODBC-Treiber für die DB die ich verwende Müll ist (Lahmarschig oder wichtige Features nicht unterstützt).
Edit: Hast du zufällig Benchmarks die belegen, dass ODBC merklich langsamer sein soll als das native API. Kann ich weder feststellen noch glauben. Die meiste Zeit geht eh für Plattenzugriffe und Netzwerk-Geraffel drauf, da dürfte der geringe Overhead den ODBC erzeugt kaum in's Gewicht fallen. Und wie oft nudelt man schon hunderttausende Datensätze auf dem Client durch (wo man es vieleicht tatsächlich spüren könnte), sowas gehört auf den Server.
-
Es macht keine Unterschied ob Server oder Client. Wenn man am Server API verwendet kann man das auch gleich am Client.