SQL dynamisch erzeugen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • SQL dynamisch erzeugen

    Hi zusammen,
    tolles Forum habt ihr hier ^^ !!

    Ich bastel gerade an einem Werkzeug, dass mit Hilfe von Dropdown Feldern dynamisch SQL generieren soll.
    Sprich wir haben 3 Dropdown-Menus (Farbe, Marke, Preisspanne) und der Code baut dann per if-then-else Konstruk (z.B., if farbe != nil, then sql = "where farbe = rot") im Hintergrund ein Query (genauer die Where Bedingung).
    Das klappt so weit ganz gut und ist auch easy. Jetzt kam aber der Wunsch, dass die Quelle dynamisch selektiert werden muss. Also habe ich Dropdownmenu gebaut, bei welchem der User die Quelle auswählt, und im Hintergrund ein String mit dem "Select * from ... " befüllt wird.
    Anschließend werden Select und Where-Bedingung zusammengepackt und abgeschickt. Alles läuft noch gut.

    Jetzt kam der Einwand, dass die Quelle nicht immer nur ein flache Tabelle ist, sondern jedes Attribut ( = Dropdown Menu) in einer andere Tabelle steht. Sprich ich müsste einen komplexeren Join bauen, der so in mein aktuelles Design m.E. nicht mehr passt.

    Mein erster Gedanke war, dass ich ein View anlege, damit ich mit meinem aktuellen Konstrukt nurnoch den Where-Filter setzen muss. Da weiß ich aber nicht, ob das alles so erlaubt ist.

    Habt ihr vielleicht eine Idee, wie ich den ersten Teil (= Selektion) möglichst statisch schreiben kann, damit ich am Ende nur noch die Where Bedingung anheften muss?
    Aktuell steht wirklich nur ganz simple "select * from tabelle1 where " in dem Selektionsfeld. Das Kritierium wird dann dynamisch angepappt "farbe = rot and marke = ford".

    VIelen Dank und Gruß,
    Easy
  • Entweder du baust einen komplexeren Join in deinem Programm, wo du dann die WHERE Bedingungen wieder durch deine Auswahl ersetzt oder du baust tatsächliche eine View, was auch gehen würde und etwas Komplexität aus deinem Programm in die Datenbank verlagert. Hätte den Vorteil, dass wenn sich die Datenbankstruktur ändert du (theoretisch) nur den View anpassen musst und nicht dein Programm.

    Aus Neugier: Delphi?
    ~ mfg SeBa

    Ich beantworte keine PMs zu Computer-/Programmierproblemen. Bitte wendet euch an das entsprechende Forum.

    [Blockierte Grafik: http://i.creativecommons.org/l/by-sa/3.0/80x15.png]
  • Hi,
    Danke für dein Feedback!

    Genau. Ich bevorzuge auch die View. Da ja in Zukunft noch mehr Quellen hinzukommen könnten und dann die Komplexität immer weiter steigt und ich in der Fallunterscheidung zum Bauen der Selektionsklausel noch eine Unterscheidung zur aktuellen Quelle brauche. Ich hatte gehofft, dass man das Query evtl. schon so weit vorbereiten kann, dass sich an meinem Programm nichts ändert. Ich hatte auf etwas in die Richtung gehofft:
    Teil 1 (fixer Teil):
    Select * from a.autoID, a.farbe, b.kaufdatum, b.preis
    from farzeug a join kauf b on a.autoid = b.autoid
    Teil 2 (wird im Backend auf Basis der Selektion generiert)
    where farbe = rot and preis = 100;


    Ich arbeite mit SAS.

    Viele Grüße,
    easy
  • ok kleines Update!
    Die Lösung ist, dass ich mit einer Kontrolldatei arbeite, welche mir die Attributnamen dynamisch erzeugt.
    Sprich ich schreibe die Where Bedingung generischt ($farbe = rot) und definiere mir in einem vorgelagerten Prozess wie die Variable $farbe aufgelöst wird (z.B. a.farbe oder b.farbe).

    Views sind leider keine Option.

    Gruß,
    easy