none
SQL-Frage RRS feed

  • Frage

  • Hallo Leute,

    meine Frage gehört eigentlich nicht ganz hierher glaube ich, aber vielleicht versteht man mich unter Foxianer  besser.

    Und ich meine das ja auch als Zugriff von Fox her. Also: Gibt es für den SQL-Server auch sowas wie seek (oder meinetwegen auch locate) ?

    Quasi nur die Frage ob ein DS mit einem bestimmten Schlüssel da ist oder nicht - oder ist das immer nur ein Select - was ja schon

    eine ganze Auswahlaktion verursacht ?

     

    Horst

     

     

    Donnerstag, 22. Dezember 2011 18:18

Antworten

  • Hallo Horst,

     

    Du auch noch hier so kurz vor Weihnachten?

    Es gibt dafür prinzipiell Exists, aber das wendet man dann ja an auf eine Unterabfrage, also dasselbe in grün.

    Aber für SQL Server gilt das gleiche wie für VFP Rushmore Optimierung: Hat SQL Server einen entsprechenden Index, schlägt es den nach und das ist insofern der Seek/Locate Ersatz. Ich bin da immer noch nicht so tief im Thema, aber SQL Server lädt im allgemeinen anders als VFP sogar die eigentlichen Daten aus dem Index statt aus den eigentlichen Tabellendaten, wenn sich das anbietet.

    Wenn Du einfach Select Count(*) machst, ist aber selbst das egal:

    SELECT Count(*) From Table Where ID = Seekwert

    => Index auf ID wird natürlich genutzt. Ergebnis 0= nicht gefunden, Ergebnis 1=gefunden, bei Foreign keys oder anderen Whereklauseln ergibt sich als Cout natürlich die Ergebnisgröße. Das kommt dem SEEK/LOCATE doch sehr nahe.

    SQLEXEC erzeugt dann einen Cursor mit einem Datensatz mit einem Feld, eine Skalarwertfunktion würde das aber auch tun, SQLEXEC erzeugt nun einmal immer einen Cursor, insofern sehe ich keinen tieferen Sinn etwas noch beseres zu suchen.

    Ich wäre allerdings auch positiv überrascht, wenn es anderes gäbe. So richtig nutzen könnte man das dann allerdings auch erst, wenn wie bei Locate oder Seek anschließend der gefundene Datensatz im Zugriff wäre, und nicht nur Found() oder die Zahl der Sätze. Und wenn man dann eben per Skip oder ähnlichem weiterscannen könnte. Für letzetres gibt es allerdings Cursoren, die den Foxpro Cursoren recht ähnlich sind, aber im Normalfall vermieden werden. Man muß dabei eben bedenken, daß jeder Cursor den Server belastetet.

    http://msdn.microsoft.com/de-de/library/ms180169.aspx

    Mit dem DECLARE CURSOR kannst Du auch ein Abfrageergebnis am Server belassen, d.h. die Daten nicht zum Client ziehen. In einem SQL Server Cursor kannst Du dann serverseitig navigieren. Insofern vergleichbar zu einem Recordset. Es ist recht verpönt, soetwas zu nutzen, wenn man stattdessen mit serverseitig ausgeführten SQLs auch zum Ziel kommt. Auch in Deinem Fall für die reine Existenzabfrage würde ich das SELECT Count(*) vorziehen.

    Ich wünsche schöne Feiertage, guten Rutsch und viel Spaß und Erfolg mit solchen Fragestellungen und Basteleien. Wenn wir uns nicht hier sowieso noch wieder lesen. Allerdings nehme ich mir jetzt auch mal zwei Wochen Forenpause vor.

    Tschüß, Olaf.

    Donnerstag, 22. Dezember 2011 20:13

Alle Antworten

  • Hallo Horst,

     

    Du auch noch hier so kurz vor Weihnachten?

    Es gibt dafür prinzipiell Exists, aber das wendet man dann ja an auf eine Unterabfrage, also dasselbe in grün.

    Aber für SQL Server gilt das gleiche wie für VFP Rushmore Optimierung: Hat SQL Server einen entsprechenden Index, schlägt es den nach und das ist insofern der Seek/Locate Ersatz. Ich bin da immer noch nicht so tief im Thema, aber SQL Server lädt im allgemeinen anders als VFP sogar die eigentlichen Daten aus dem Index statt aus den eigentlichen Tabellendaten, wenn sich das anbietet.

    Wenn Du einfach Select Count(*) machst, ist aber selbst das egal:

    SELECT Count(*) From Table Where ID = Seekwert

    => Index auf ID wird natürlich genutzt. Ergebnis 0= nicht gefunden, Ergebnis 1=gefunden, bei Foreign keys oder anderen Whereklauseln ergibt sich als Cout natürlich die Ergebnisgröße. Das kommt dem SEEK/LOCATE doch sehr nahe.

    SQLEXEC erzeugt dann einen Cursor mit einem Datensatz mit einem Feld, eine Skalarwertfunktion würde das aber auch tun, SQLEXEC erzeugt nun einmal immer einen Cursor, insofern sehe ich keinen tieferen Sinn etwas noch beseres zu suchen.

    Ich wäre allerdings auch positiv überrascht, wenn es anderes gäbe. So richtig nutzen könnte man das dann allerdings auch erst, wenn wie bei Locate oder Seek anschließend der gefundene Datensatz im Zugriff wäre, und nicht nur Found() oder die Zahl der Sätze. Und wenn man dann eben per Skip oder ähnlichem weiterscannen könnte. Für letzetres gibt es allerdings Cursoren, die den Foxpro Cursoren recht ähnlich sind, aber im Normalfall vermieden werden. Man muß dabei eben bedenken, daß jeder Cursor den Server belastetet.

    http://msdn.microsoft.com/de-de/library/ms180169.aspx

    Mit dem DECLARE CURSOR kannst Du auch ein Abfrageergebnis am Server belassen, d.h. die Daten nicht zum Client ziehen. In einem SQL Server Cursor kannst Du dann serverseitig navigieren. Insofern vergleichbar zu einem Recordset. Es ist recht verpönt, soetwas zu nutzen, wenn man stattdessen mit serverseitig ausgeführten SQLs auch zum Ziel kommt. Auch in Deinem Fall für die reine Existenzabfrage würde ich das SELECT Count(*) vorziehen.

    Ich wünsche schöne Feiertage, guten Rutsch und viel Spaß und Erfolg mit solchen Fragestellungen und Basteleien. Wenn wir uns nicht hier sowieso noch wieder lesen. Allerdings nehme ich mir jetzt auch mal zwei Wochen Forenpause vor.

    Tschüß, Olaf.

    Donnerstag, 22. Dezember 2011 20:13
  • Hahahaha - unglaublich, ich hatte heute (vor Weihnachten?) wirklich nicht mehr mit einer Antwort gerechnet

    Danke Olaf , Du Unentwegter.Hat mir nun weitergeholfen.

    Ja , es ging mir im Kern auch hauptsächlich um Serverauslastung bzw. Leitungsbelastung, damit verbundene Performance

    und dergl.

    Ja, gönn Dir man ein bißchen Ruhe, Motivation und Power sind hinterher umso besser.

    Ich wollt mich eigentlich auch schon mal wieder in HH blicken lassen aber ich habe bis 20.00 am gleichen

    Tag in Hannover immer eine Veranstaltung. Mal sehen wie ich das in Zukunft regele.

    Und wenn wir uns hier tatsächlich die nächsten Tage nicht mehr "sehen" : ebenfalls frohes Fest

    und komm gut ins Neue Jahr.

     

    Ciao Horst

    mit den besten Grüßen aus dem WBL

     

    Donnerstag, 22. Dezember 2011 21:46