MB: Frei verfügbares SQL Element Lexikon (Rückgabetyp & Parametertyp) (de/en)

moin,

gibts einen Art Lexikon in dem steht, was für Parameter Typen SQL-Elemente erwarten und was für einen Werttyp sie zurück geben? Kann auch gern englisch sein. Das ist für mich relevant da ich dadurch mit interfaces arbeiten kann.

Ich hab, wie immer, im internet gesucht und auch Dokumente von Microsoft, Oracle, MySQL gefunden, die das beschreiben, überflogen aber völlig unterschiedlich je nach herstellen 😕. Daher meine Frage.

Nachtrag:

Ich will diese "SQL Interface Struktur" in mein PHP System einbinden um exakter arbeiten zu können.

lgmb

--
Sprachbehinderung

akzeptierte Antworten

  1. Hallo MB,

    kann Dir gerade nicht folgen. Was verstehst Du unter SQL Elementen? Eingebaute Funktionen? Die sind im Handbuch der jeweiligen Datenbank dokumentiert. Den Typenreichtum von SQL erreichst Du in PHP aber ohnehin nicht.

    Ansonsten sind eigentlich die einzigen getypten Dinge in SQL nur die Tabellenspalten, und deren Typ legst Du selbst fest. Um sie nach PHP zu übertragen, kannst Du Bindung verwenden, aber beim Binden von Parametern oder Rückgabewerten bist Du auf die PDO::PARAM_* Werte beschränkt. Da es dort FLOAT oder DATE nicht gibt, kommen die (glaube ich) als String an und du musst das dann selbst konvertieren.

    Holst Du ein Ergebnis ohne Bindung, kommen - glaube ich - ohnehin alle Werte als String an.

    Rolf

    --
    sumpsi - posui - clusi
    1. moin,

      Was verstehst Du unter SQL Elementen?

      Sry, BETWEEN, CASE, IN

      Eingebaute Funktionen?

      Korrekt!

      Die sind im Handbuch der jeweiligen Datenbank dokumentiert.

      Nur unter anderen Bezeichnungen. Ich bin an einem anderen Computer sodass ich die Seiten als Belege, die ich angeführt haben hier nicht mehr habe, sry. Aber ich such sie raus momentchen.

      Den Typenreichtum von SQL erreichst Du in PHP aber ohnehin nicht.

      Schon klar. Ich hab mich ja auch Tabellen, Spalten und und AS auf ein übergeornetes Interface ContextInterface gesetzt.

      Alle weiteren Typen LiteralInterface gesetzt. Z.B. new Literal ( '2020-03-02' ) Damit es nicht proprietät ist. CONCAT(), STRING() habe ich ganz rausgelassen, da sie, glaube ich, proprietät sind und man das ja schon ganz gut in PHP intern machen kann.

      lgmb

      --
      Sprachbehinderung
      1. moin,

        Die sind im Handbuch der jeweiligen Datenbank dokumentiert.

        Nur unter anderen Bezeichnungen. Ich bin an einem anderen Computer sodass ich die Seiten als Belege, die ich angeführt haben hier nicht mehr habe, sry. Aber ich such sie raus momentchen.

        Ok, ich finde blöderweise die URLs hier auf meinem System nicht 😕. Sry dafür. Ich hols nach und werde auf jedenfall morgen auf dem anderen Rechner nachschauen und (dir|euch) die Urls posten - wenn ich es nicht vergesse 😟.

        lgmb

        --
        Sprachbehinderung
    2. moin,

      […] Die sind im Handbuch der jeweiligen Datenbank dokumentiert.

      Nur unter anderen Bezeichnungen. […]

      Sry, das ich erst jetzt schreibe. Ich hab die Tabs auf meinem anderen System hier.

      Ich meine nicht hier die DBMS und SQL Datentypen wie: BIGINT, DECIMAL, DOUBLE PRECISION, INTEGER, REAL, SMALLINT,

      Ich meine die für mich unekannten Datentypen, di vermute ich mal propietär sind:

      Ich hoffe, ich habs hinreichend, veranschaulicht. Wenn nicht bitte Frag. Ich hättes blöderweise in die Eingangsfragen stecken müssen 😕. Sry

      Bei diesem Internet Dokumentations-Chaos mit Datentypen unterschiedlicher Bezeichnungen verlore ich den Überblick 😕.

      Nachtrag: Ich hab übrigend -natürlich in vereinfachter Form - selbst überlegt, was für Intefaces, die mit mehr Ausdruck, nehme kann und ich werde, denke ich mal, dann auch so zurecht kommen 😉.

      lgmb

      --
      Sprachstörung
      1. Hallo MB,

        da schmeißt Du aber jetzt gewaltig was durcheinander.

        Bist Du darauf angewiesen, Datenbanken wie InterSystems oder Oracle zu unterstützen? Oder willst du das einfach?

        Wenn Du es willst, dann überlege Dir gut, welche proprietären Features (also das, was nur diese konkrete DB kennt und kein SQL Standard ist) einer dieser Datenbanken Du anbieten willst. Ein SQL Generator bildet einen kleinsten gemeinsamen Nenner aller unterstützten Datenbanken ab. Du willst damit doch erreichen, dass Du den Application Code unverändert lassen kannst und nur den SQL Generator austauschen musst, um eine andere DB zu unterstützen. Und Du musst es ja auch testen können, d.h. du brauchst Installationen aller Datenbanken die Du unterstützen willst. Nur mit dem Handbuch zu programmieren, ohne konkrete Läufe auf einer Maschine, ist mutig.

        Bei Intersystems hast Du keine Typen gefunden, sondern Operatoren. Ich habe mir jetzt nur %INLIST angeschaut, damit geht laut dieser Seite etwas, was andere SQLs nur aus ihren feuchten Träumen kennen: spaltexy %INLIST ?. Zumindest MS SQL Server kennt keine Werteliste, die man per Parameter-Marker für eine Abfrage "ist der Wert in dieser Liste enthalten" angeben kann. In MySQL 8 scheint da mit MEMBER_OF etwas gekommen zu sein. Jedenfalls ist das etwas, das hoch proprietär ist und was dein Generator bei DBs, die das nicht kennen, irgendwie nachbauen müsste.

        Bei Oracle hast Du keine Wertetypen gefunden, sondern eine Unterteilung von Expressions. Welchen (Werte-)Typ die haben, hängt davon ab worauf man sie anwendet. Steht ja auch drüber: General expressions are expressions that might result in a value of any type. Eine Column Reference ist ein Ausdruck, der eine Spalte bezeichnet. name ist eine Column Reference, bestehend aus einem Spaltennamen. foo.name ist eine Column Reference, bestehend aus einem Table- und einem Spaltennamen.

        Bei Oracle steht zwar "Expression Type" drüber, aber das meint keine Datentypen. Sprache ist oft genug mehrdeutig.

        Was Du bei Microsoft gefunden hast, hat mit SQL überhaupt nichts zu tun, da geht es um SSRS (SQL Server Reporting Services), die eine eigene Syntax haben.

        Was Du bei techrepublic gefunden haben willst, weiß ich nicht. Das sieht mir wie ein normales Tutorial für Subselects aus.

        Rolf

        --
        sumpsi - posui - clusi
        1. Tach!

          Wenn Du es willst, dann überlege Dir gut, welche proprietären Features (also das, was nur diese konkrete DB kennt und kein SQL Standard ist) einer dieser Datenbanken Du anbieten willst. Ein SQL Generator bildet einen kleinsten gemeinsamen Nenner aller unterstützten Datenbanken ab. Du willst damit doch erreichen, dass Du den Application Code unverändert lassen kannst und nur den SQL Generator austauschen musst, um eine andere DB zu unterstützen.

          In aller Regel implementieren derartige Abstraktionslayer nur die 08/15-Vorgänge. Damit hat man einerseits genug zu tun, und erschlägt andererseits einen sehr großen Anteil der Anwendungsfälle. Für den Rest kann man vorsehen, dass der allgemeine Prepared-Statement-Mechanismus auch zur Verfügung steht, über den der Verwender beliebiges SQL ausführen kann. Damit ist man frei, die Gegebenheiten des DBMS auszunutzen. Dass man sich so aber die einfache Austauschbarkeit des DBMS verbaut, ist dann halt so. Aber so häufig kommt das auch nicht vor.

          dedlfix.

        2. moin,

          da schmeißt Du aber jetzt gewaltig was durcheinander.

          Ich befürchte das auch jetzt auch 😕

          Bist Du darauf angewiesen, Datenbanken wie InterSystems oder Oracle zu unterstützen? Oder willst du das einfach?

          Sry, Will ich was einfach???

          Wenn Du es willst, dann überlege Dir gut, welche proprietären Features […] einer dieser Datenbanken Du anbieten willst.

          Will ich ja nicht

          Ein SQL Generator bildet einen kleinsten gemeinsamen Nenner aller unterstützten Datenbanken ab.

          Das will ich

          Bei Oracle hast Du keine Wertetypen gefunden, sondern eine Unterteilung von Expressions.

          Bei Oracle steht zwar "Expression Type" drüber, aber das meint keine Datentypen. Sprache ist oft genug mehrdeutig.

          Was Du bei Microsoft gefunden hast, hat mit SQL überhaupt nichts zu tun, da geht es um SSRS (SQL Server Reporting Services), die eine eigene Syntax haben.

          Was Du bei techrepublic gefunden haben willst, weiß ich nicht. Das sieht mir wie ein normales Tutorial für Subselects aus.

          Danke. Da reicht mir.

          lgmb

          --
          Sprachstörung
          1. Hallo MB,

            Oder willst du das einfach?

            Sry, Will ich was einfach???

            Die Frage richtete sich auf die Motivation, InterSystems (wovon ich noch nie gehört habe) und Oracle (wovon ich gehört, es aber noch nie benutzt habe) zu unterstützen. Gibt es einen Anwendungsfall, wofür Du das brauchst, oder steht die Unterstützung dieser Datenbanken auf deiner persönlichen "Das will ich können" Agenda.

            Aber ich glaube, die Frage hat sich erledigt. Du hast einfach global nach Informationen gesucht und bist von der Masse überflutet worden...

            Rolf

            --
            sumpsi - posui - clusi
            1. moin,

              Gibt es einen Anwendungsfall, wofür Du das brauchst, oder steht die Unterstützung dieser Datenbanken auf deiner persönlichen "Das will ich können" Agenda.

              Nö, ich will einfach nur nen Universal SQLGenerator entwickeln mit PDO Anbindung. Ich will erreichen, dass das Query validiert "sauber" zur Datenbank geschickt wird. PHP Intern kann man ja noch ne Menge anstellen, bezogen auf die Resultate die man ja fetcht.

              Aber ich glaube, die Frage hat sich erledigt. Du hast einfach global nach Informationen gesucht und bist von der Masse überflutet worden...

              Exakt! Du hast die Faus auf Auge geschlage 😀.

              lgmb

              --
              Sprachstörung
    3. moin,

      ich hab jetzt eine Idee die ich entwickeln werde bezüglich Interfaces

      class Between extends AbstractConstruct implements FilterInterface, CountableExpressionInterface { /* .... */}
      
      class Numeral extends AbstractConstruct implements CountableValueInterface, CountableValueInterface { /* ... */}
      

      so kann man die Interfaces näher differenzieren und anstatt das…

      // Between
      
      public function __construct (
        ConstructInterface $value,
        ConstructInterface $minimum,
        ConstructInterface $maximum,
        bool $negation = false,
        bool $safe = false // fuer bindParam()
      ) { /* ... */ }
      

      …dass…

      // Between
      
      public function __construct (
        ConstructInterface $value,
        CountableExpressionInterface $minimum,
        CountableExpressionInterface $maximum,
        bool $negation = false,
      ) { /* ... */ }
      

      …sodass man zumindest in der Initialisierung der Between-Klasse prüfen kann, ob das die übergebene Objekte $maximum und $minimum, die das Interface CountableExpressionInterface, was ja Konstruktorparameter ist, auch CountableValueInterface implementieren. So kann man diese Beiden in ein bindeParam() packen, weil diese beiden Konstanten sind wie 8, 'foobar', '%somthing_'. Da hab ihr, Du und @Felix Riesterer, mich aufgeklärt 😀. Dafür mich ich sehr dankbar.

      lgmb

      --
      Sprachstörung