Beispielsammlung SQL Select Commands

verwendetes Datenbanksystem: SQL Server

Hi, ich schreibe gerade eine Klasse, die zumal SQL-Abfragen parsen und diese anschließend weiter verarbeiten soll.

Eigentlich habe ich die Klasse soweit auch fertig, mir fehlt scheinbar nur noch eine Test-Unit.

Kennt jemand von euch eine Quelle, wo es zu jedem Select-Feature ein Beispiel-Select gibt?
Ziel ist halt, dass ich meine Klasse mit so vielen SQL-Abfragen testen kann wie möglich und das halt in allen möglichen Konstellationen, die mir MSSQL bei Select-Abfragen bietet.

Wenn es so eine Sammlung schon gibt, spare ich viel Zeit 😉

Fangfrage:
Wie sollen wir ohne Tabellen Struktur und DB Infos wissen was du mit dem Select auswählen kasst?

Mal davon abgesehen, dass sich mir der Sinn deines Vorhabens ohne Code nicht erschließt.
Willst du deine CRUD Umsetzung testen oder willst du einfach nur schauen ob die aus deiner Test DB/Tabelle die Daten mit unterschiedlichen ggf. sogar Praxisfernen Abfragen auslesen kannst?

Was ist dein Ziel mit der Umsetzung die du gebaut hast?
Ohne Details ergibt deine Anfrage keinen Sinn.

T-Virus

Wie sollen wir ohne Tabellen Struktur und DB Infos wissen was du mit dem Select auswählen kasst?

Die Frage verstehe ich nicht. Wozu musst du irgendwelche DB-Strukturen wissen?
Es ist eine Klasse, die ein SQL Select-Statement parst und dann weiter verarbeitet. (Where-Clause extrahieren, Tabellennamen extrahieren usw.)
Es gibt dazu keine Datenbank, denn erstmal ist es wie gesagt nur eine Klasse die etwas parst.
Man kann doch eine SQL-Abfrage parsen (in einzelne Teile zerlegen) ohne, dass man die DB-Abfrage zu irgendeinem Server schicken muss...

Was ist dein Ziel mit der Umsetzung die du gebaut hast? Suche: SQL-Statement-Modifier
Auch wenn ich mich frage, wozu du wissen musst, was ich vorhabe, um zu sagen ob du so eine Select-Sammlung kennst oder nicht...? 😉

Du hättest eigentlich schon in dem anderen Thread erkennen können, dass den Lesern und Helfern nicht so 100% klar ist, was Du da vor hast und wozu das dienen soll.
Dahingehend ist es auch sehr schwer zu sagen, ob es eine Sammlung gibt oder nicht.
Ich verstehe zB nicht mal, was Du überhaupt von der Sammlung sowohl inhaltlich wie auch formal erwartest bzw. Du Dir vorstellst.

Je nach DBMS können sich die Befehle mal mehr mal weniger unterscheiden.

Ich glaube das MorphieX einfach einen T-SQL Parser gebaut hat und nun eine möglichst große unterschiedliche Vielzahl an Select Statements sucht um möglichst sämtliche Aspekte seiner Implementation testen.

Daraus ergibt sich für mich:
Recht hat MorphieX das man für seine Anforderung nichts über irgendwelche Strukturen zu wissen braucht weil sein Parser ja nur Statements parsed. Dafür braucht man kein Hintergrundwissen über DB Details.
Ein Statement wie

Select [Ergebnis Spalte] AS Result from MeineTabelle WHERE Suchspalte1 IN (Select Keyfeld from [dbo].[Table] WHERE [Feld Gelöscht] = 0)

wäre meinem Verständnis schon die Erfüllung seiner Anfrage. Natürlich sucht er so etwas aber in Masse.

MorphiX' Anfrage macht aber nur bedingt Sinn meines Erachtens nach, weil Unit Testing so nicht funktioniert. Man kann sich zwar sicherer fühlen je mehr unterschiedliche Testdaten man hat, aber ich finde das man Implementationen modular testen sollte. Teile (Methoden) sollten für sich selbstständig getestet werden und funktionieren und hierfür benötigt man dann idealerweise nur kleinere Mengen an Testfällen um eben nur die möglichen Ablaufwege eines Teils (Methode) vollständig zu testen. "Code coverage" ist das Stichwort. Wer 100% Code coverage hat sollte sich sicher sein können das die Implementation alle Anforderungen zu 100% erfüllt und diese auch mit Unit Tests abdeckt.

Wenn du MorphiX aber diese Statements suchst um überhaupt herauszufinden welche Fälle alles auftreten können, so finde ich das dies der falsche Ansatz ist.
Wenn du einen vollständigen Parser bauen willst solltest du lieber die komplette Spezifikation abbilden (SELECT (t-SQL))
(Und das ist eine Menge ... 😉)

Ob es Sinn macht seinen eigenen T-SQL Parser zu implementieren ist eine andere Frage.
Willst einen Parser bauen weil du denkst es gibt nichts fertiges?
Oder weil alles was es gibt nicht deinen Anforderungen genügt?
Oder einfach zur Übung aus Spaß an der Freud'?

Ich werde aus der Umsetzung auch so nicht schlau.
Welchen Sinn hat hier ein eigener Parser?

Ohne Hintergrundwissen warum dies umgesetzt wurde, ergibt sich für mich aus meiner Sicht kein brauchbares Szenario in dem ich einen Parser schreiben möchte.
Sowas klingt meistens nach irgendwelchen Verarbeitungen die man ggf. für eine eigene SQL basierte Datenbank umsetzen will.
Aber ohne Hintergrundinfos was der Zweck der Umsetzung ist, kann ich auch nicht genau sagen weshalb du die Statements brauchst.
Die Select Anweisung kann dermaßen ausarbeiten, dass dein Parser sogar mehrfache Sub Selects abfangen müsste.
Aber das sind auch Dinge die man durch da lesen der Doku und generellen Sql Know How wissen müsste.
Die Kombinationen sind dermaßen unterschiedlich, dass du hier keine volle Liste bekommen wirst.
Schau dir z.B. die Beispiele bei MSDN per T-SQL und speziell Select an.
Da bekommst du den groben Aufbau der eine Select Anweisung haben kann.
Den Rest kannst du dann selbst zusammen bauen oder googeln.

Nachtrag:
Ich frage deshalb nach dem Sinn und Zweck des ganzen, da ohne diese Details es keinen Sinn machen würden irgendwelche Select Statements hier aufzulisten.
Wenn du kein konkretes Entwicklungsproblem hast, bist du mit deiner Anfrage hier falsch.
Für Select Anweisungen kannst du Google und MSDN für T-SQL Select Aufbau abfragen.
Im Forum wird sich keiner die Mühe machen die schier endlosen Kombinationen von Select Statements zusammen zu bauen.
Das ist deine Aufgabe.

T-Virus

@T-Virus
Das hat er aber in dem verlinkten Thread erklärt wozu er meint das zu brauchen.

witte, eigentlich wissen wir auch aus dem alten Thread nur die Info aus

wir nutzen zur Zeit eine Anwendung die genau so funktioniert - und das ist wirklich klasse!

Dass man das Vorgehen statt "klasse" im Allgemeinen eher als höchst fragwürdig und in meinen Augen auch unfassbar fahrlässig bezeichnen kann, das ist im Prinzip MorphieX's Problem.

MorphieX wird trotzdem (mit sehr sehr hoher Wahrscheinlichkeit) keine Sammlung für so einen Anwendungsfall finden.
Zum einen aus den Gründen, die hummigbird1 meinte (...komplette Spezifikation abbilden...) und zum anderen, da ich bezweifle, dass auch nur irgendwer anners auf so eine Idee kommt, das so (unsicher) umzusetzen 😃

Ich habe mir den anderen Thread mal durchgelesen.
Mal davon ab, dass es sinnvoller wäre diesen weiter zuführen als einen neuen aufzumachen, halte ich die Idee auch für sehr fragwürdig.

Das was ihr dort macht, ist wie Abt schon im anderen Thread geschrieben hat, höchst kritisches Zeug.
Entweder kann man damit die DB zerstören, löschen, zu müllen oder sonstigen Mist machen.
Keine Ahnung was ihr damit genau macht, aber ich würde das nicht mal mit einer geladenen Waffe auf der Brust nutzen wollen.

Außerdem hebelt ihr mit dem Kram dermaßen viele Sicherheitsmechanismen aus, dass es schon wehtut.
Sowohl auf Sql Parameter wird dabei verzichtet, was sowohl Performance als auch Sicherheit kostet.
Ebenfalls kann mit dieser Umsetzung eben auch viel Unfug gemacht werden.
Wenn man das böswillig umsetzt, macht man eine Sql Injection und liest die ganzen Benutzerdaten aus.
Wenn die DB dahinter dann noch fahrlässigerweise die Daten im Klartext hat, kann man Emails und co. auslesen.
Ich für meinen Teil kann euch nur dingend ans Herz legen, das Thema einzustampfen.
Ihr spielt hier mit dem Feuer.

T-Virus

Ja, schon klar, anti pattern "inner platform effect".
Ich würde versuchen sowas mit Linq Expressions abzubilden und dann mit Proxies etc weitere Bediningungen in die Expression zu injizieren.

So, es ist Montag und ich fange mal an:

Du hättest eigentlich schon in dem anderen Thread erkennen können, dass den Lesern und Helfern nicht so 100% klar ist, was Du da vor hast und wozu das dienen soll.

Und deswegen habe ich hier einen getrennten Thread für eine konkretere Frage aufgemacht, nämlich nach der Frage ob hier jemand so eine Sammlung kennt. Diese Frage lässt sich nur mit Nein oder Ja und ggf. mit einem Link zur Sammlung beantworten. Hier wird aber wieder über Sinn und Unsinn für mein Projekt diskutiert.
Geht ihr mit so einer Argumentation auch an eure Kunden, wenn diese (Administratoren) so einen Wunsch äußern?

Dahingehend ist es auch sehr schwer zu sagen, ob es eine Sammlung gibt oder nicht.
Ich verstehe zB nicht mal, was Du überhaupt von der Sammlung sowohl inhaltlich wie auch formal erwartest bzw. Du Dir vorstellst.

Wie hummigbird1 schon richtig festgestellt hat, suche ich eine Sammlung an Select-Abfragen, die ein möglichst großes Spektrum an verschiedenen SQL-Select-Features abbilden.
Es ist gut möglich, dass ich irgendein Feature noch nicht vollständig berücksichtigt habe, daher die Frage nach einer Sammlung die möglichst alle Features berücksichtigen.

Ich glaube das MorphieX einfach einen T-SQL Parser gebaut hat und nun eine möglichst große unterschiedliche Vielzahl an Select Statements sucht um möglichst sämtliche Aspekte seiner Implementation testen.

Nicht ganz. Ich nutze den SQL-Parser von Microsoft (TSQLParser) um das Selectstatement zu parsen. Dabei gehe ich dann möglichst jede Tabellenreferenz durch und rufe aus meiner Klasse ein Event auf, in dem man die zur Tabellenreferenz gehörende Where-Clause modifizieren (erweitern) kann.
Die Schwierigkeit dabei ist, wirklich jede Tabellenreferenz zu finden, z.B. in SubSelects, Unions, Joins,...
Ich denke den Großteil konnte ich schon abdecken, aber möglicherweise habe ich noch bestimmte Konstellationen übersehen.

Ohne Hintergrundwissen warum dies umgesetzt wurde, ergibt sich für mich aus meiner Sicht kein brauchbares Szenario in dem ich einen Parser schreiben möchte.

Ein Beispiel ist eine automatische Filterung nach Mandanten. Hier wird z.B. jede Abfrage in meinem DAL über meinen SQLModifier gejagt und anhand einer Einstellung (welche Tabelle ist mandantisiert? Welche Tabellen haben übergreifende Daten etc.) wird die Where-Clause erweitert.
In meinem Programm muss ich dann nur noch allgemeine SQL-Abfragen formulieren und muss die Mandantisierung dabei nicht berücksichtigen, denn hier kann der Administrator sehr flexibel die Mandantenbeziehungen einstellen.

Ein zweites Beispiel wäre die automatische Filterung von Daten. Z.B. kann ein User Administrator (meine User sind Entwickler) für bestimmte Tabellen selbstdefinierte Datenfilter setzen.

Wenn du kein konkretes Entwicklungsproblem hast, bist du mit deiner Anfrage hier falsch.

Richtig, es ist kein Entwicklungsproblem sondern eine Frage, ob jemand zufällig schon so eine Sammlung hat. Ich wusste nicht dass man das hier nicht fragen darf.

Im Forum wird sich keiner die Mühe machen die schier endlosen Kombinationen von Select Statements zusammen zu bauen.
Das ist deine Aufgabe.

Das habe ich auch nicht erwartet, es war nur eine einfache Frage!

Dass man das Vorgehen statt "klasse" im Allgemeinen eher als höchst fragwürdig und in meinen Augen auch unfassbar fahrlässig bezeichnen kann, das ist im Prinzip MorphieX's Problem.

Genau so fahrlässig wie das Absetzen von eigenen SQL-Abfragen aus dem SQL-Manangement-Studio...
Wir haben sicherlich unterschiedliche Anwenderkreise. Ich halte das gezielte Manipulieren von SQL-Abfragen nicht für fahrlässig, sondern für ein Must-Have-Feature in meiner Software.

Außerdem hebelt ihr mit dem Kram dermaßen viele Sicherheitsmechanismen aus, dass es schon wehtut.
Sowohl auf Sql Parameter wird dabei verzichtet, was sowohl Performance als auch Sicherheit kostet.
Ebenfalls kann mit dieser Umsetzung eben auch viel Unfug gemacht werden.
Wenn man das böswillig umsetzt, macht man eine Sql Injection und liest die ganzen Benutzerdaten aus.
Wenn die DB dahinter dann noch fahrlässigerweise die Daten im Klartext hat, kann man Emails und co. auslesen.
Ich für meinen Teil kann euch nur dingend ans Herz legen, das Thema einzustampfen.
Ihr spielt hier mit dem Feuer.

Natürlich wird der Produktivcode auf Parameter setzen, aber das ist halt Sache der Implementierung im DAL und hat erstmal nichts mit dem SQLModifier selbst zutun.
Bitte erkläre mir aber mal, wie ich mit einem SQL-Select die DB zerstören, Daten löschen oder zumüllen kann?
Ich grenze meine Ergebnismenge schließlich nur weiter ein.
Anstatt in jedem SQL-Statement die Mandantenspezifischen Sachen in der Where-Clause von hand zu definieren, macht mein Programm dies automatisch. Das tatsächliche SQL-Statement entspricht anschließend also dem, was ich sonst hardcodiert in die Abfrage geschrieben hätte...

Ich würde auf jeden Fall eine Software bevorzugen, die so eine Funktion zum Zerschießen der Datenbank gar nicht erst anbietet. Also benutzt du lieber Notepad als das SQL-Manangement-Studio, weil man mit dem Studio ja die Datenbank zerschießen kann und in Notepad nicht?! Hä?