Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] DBMS-übergreifendes SQL

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] DBMS-übergreifendes SQL

    Hallo,

    ich mache mir seit einigen Tagen Gedanken über die Entwicklung einer Datenbank-Schnittstelle, die ausschließlich mit in Klassen abgebildetem SQL arbeitet und DBMS-unabhängig ist. Das bedeutet:

    Die Schnittstelle ist modular aufgebaut. Sie kann beliebige Module zur Ansteuerung von diversen Datenquellen (Mysql, Postgresql, XML, ...) laden und dann quellenübergreifende Queries ausführen, d.h. innerhalb eines Queries können Datensätze aus verschiedenen Quellen stammen (Tabelle A ist Mysql, Tabelle B ist XML, etc.).

    Kann jemand von euch mit Erfahrungen mit sowas dienen oder Ideen für die Umsetzung äußern?

    Das hier ist keine Howto-Anfrage!


  • #2
    Zitat von Saraneus
    und dann quellenübergreifende Queries ausführen, d.h. innerhalb eines Queries können Datensätze aus verschiedenen Quellen stammen (Tabelle A ist Mysql, Tabelle B ist XML, etc.).
    Über ein einzelnes Objekt willst Du Tabellen verschiedener Datenbanken(-server) ansprechen? Als vereinfachter Code
    PHP-Code:
    <?php
    $ds 
    = new Foobar($parameters);
    $r1 $ds->query('Abfrage für Tabelle x'); // Quelle: sqlite
    $r2 $ds->query('Abfrage für Tabelle y'); // Quelle: postgre
    ?>
    Wo kommt die Zuordnung x-> sqlite/Datenquelle#1, y->postgre/Server#n her?
    Solche Datenbank-Abstraktionen kenne ich nicht. Wenn, dann gibt es soetwas mind. eine Stufe höher angesiedelt. Da, wo es schon egal ist, ob es eine Datenbank oder sonst irgendeine Datenquelle ist.

    Kommentar


    • #3
      Nein. Nehmen wir folgenden Query an:

      Code:
      SELECT * FROM tabelleA, tabelleB WHERE tabelleB.foreignId = tabelleA.Id
      Die Datensätze aus tabelleA kommen von einer Mysql-DB, die aus tabelleB von einer XML-Datei.

      Die Zuordnung passiert zB per XML, in der die gesamte für die Anwendung relevante Datenstruktur definiert ist. Zu jeder Tabelle existiert ein mögliches Attribut, das den Bezug zur Schnittstelle herstellt. Eine Query-Methode sucht sich also für jede abgefragte Tabelle die zugehörige Schnittstelle und bastelt so die Abfrage und das Ergebnis zusammen.

      NATÜRLICH soll es eine Optimierung für den Fall geben, in dem nur eine einzige Schnittstelle erwartet wird. In diesem Fall wird dann eben ein echter SQL-Query gebildet und an EINE Schnittstelle geschickt.

      Sinn des ganzen ist es einerseits, eine äußerst flexible Datenanbindung zu haben, die in jedem Fall funktioniert, andererseits darauf aufbauend will ich eine Formularabstraktion basteln, die mit der Datenschnittstelle arbeitet und ebenso flexibel ist, z.B. endlose Verschachtelung von Datensatzverknüpfungen beim Eintragen von zB Adressen verbunden mit Orten verbunden mit Ländern verbunden mit Kontinenten verbunden mit Planeten etc..

      Eigentliches Ziel: Nie wieder Formulare schreiben!

      Kommentar


      • #4
        Das problem wird doch sein, dass man für alle Operationen die über 2 Tabellen gehen, sämtliche Daten erstmal rüber in php schauffeln muss, weil ich kaum glaube, dass mysql mit mssql, ner xml-datenbank oder sonstwas direkt kommuniziert und der overhead der da entsteht dürfte sämtliche querys extrem langsam machen.

        Oder hab ich da was falsch verstanden ?
        robo47.net - Blog, Codeschnipsel und mehr
        | Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

        Kommentar


        • #5
          Verstehe ich immer noch nicht, warum das bereits auf der Ebene der Datenbankschnittstelle passieren muss.
          WHERE tabelleB.foreignId = tabelleA.Id
          An dieser Stelle benutzt ein dbms (rein) interne Daten, um die gewünschte Verknüpfung schnell herzustellen. Das kann Dein ...hm, wie kan man das nennen?... Meta-dbms nicht leisten.
          Ich frag mal morgen unseren Chef-Datenbankler, ob er von sowas schon mal gehört hat. Aber Zweifel bleiben.

          Sinn des ganzen ist es einerseits, eine äußerst flexible Datenanbindung zu haben, die in jedem Fall funktioniert, andererseits darauf aufbauend will ich eine Formularabstraktion basteln, die mit der Datenschnittstelle arbeitet und ebenso flexibel ist, z.B. endlose Verschachtelung von Datensatzverknüpfungen beim Eintragen von zB Adressen verbunden mit Orten verbunden mit Ländern verbunden mit Kontinenten verbunden mit Planeten etc..

          Eigentliches Ziel: Nie wieder Formulare schreiben!
          Da fällt mir spontan nur http://www.joelonsoftware.com/articl...tractions.html zu ein

          Kommentar


          • #6
            Jain.

            Datensätze würden sich teilweise auch zeilenweise holen lassen. Bei komplizierten Anfragen muss halt gecacht werden. Man könnte zB auch sog. Views anlegen, die solche übergreifenden Abfragen cachen.

            Kommentar


            • #7
              Ich sehe irgendwie den reelen Nutzen nicht...
              Klar ich kann XML oder SQL-Ergebnisse verschachteln/kombinieren/voneinander abhängig machen, aber wozu? Das mach ich lieber optimiert auf das Problem mit speziellen PHP-Abfragen.

              Kommentar


              • #8
                du könntest eigentlich lieber http://propel.phpdb.org weiterentwickeln, das ding hat das selbe ziel:
                * definition der datenbank-schemata in XML,
                * dynamisches erzeugen der datenbank-spezifischen queries als php-klassen
                * neu-generierung der tabellen und zuweisungen bei dbms-wechsel und/oder schemawechsel
                * portierung vom einen DBMS zum anderen wäre ein unglaublich starkes feature.

                generische klassen, die komplette DBMS-unabhängig sind, sind wohl noch nicht ganz möglich, allein die daraus entstehende anforderung, sich nur auf den kleinsten gemeinsamen nenner der SQL-sprachsyntax zu verlassen, würde performante datenbank-abfragen (die besonderheiten des DBMS ausnutzen, um schneller zu werden) ausschließen.


                grüße
                axo

                Kommentar


                • #9
                  Zitat von axo
                  generische klassen, die komplette DBMS-unabhängig sind, sind wohl noch nicht ganz möglich, allein die daraus entstehende anforderung, sich nur auf den kleinsten gemeinsamen nenner der SQL-sprachsyntax zu verlassen, würde performante datenbank-abfragen (die besonderheiten des DBMS ausnutzen, um schneller zu werden) ausschließen.
                  Zitat von Saraneus
                  NATÜRLICH soll es eine Optimierung für den Fall geben, in dem nur eine einzige Schnittstelle erwartet wird. In diesem Fall wird dann eben ein echter SQL-Query gebildet und an EINE Schnittstelle geschickt.
                  Ein solches Tool schließt die DBMS-spezifischen Features nicht aus. Wer möchte, kann mit dem Ding ja auch low- oder lower-level arbeiten.

                  Kommentar


                  • #10
                    Ich bin da sehr skeptisch. Der Einsatz einer "gewöhlichen" Abstraktionsschicht sollte ja schon gut
                    abgewägt sein, da die Datenbankverbindung ja in der Regel der Flaschenhals ist. Hier noch Treiber
                    zwischenzuschalten und die Abfragesprache auf den kleinsten Nenner zu drücken muss schon einen
                    großen Nutzen haben gegenüber für ein DBMS optimierten Abfragen.

                    In deinem Fall kommt aber noch dazu, dass du die Query auswerten musst und auch bei einer
                    zeilenweisen Abarbeitung (gegenüber dem kompletten Laden zumindest der ersten Tabelle in den
                    Hauptspeicher (ein Zwischenlagern auf der Platte wäre ja noch krasser - wird aber bei größeren
                    Datenmengen unabdingbar)) hast du einen extremen Overhead.

                    Einzig sinnvolle fände ich, wenn eine gemeinsame Datenbank mit anderen Datenquellen
                    Synchronisiert wird. Diese Synchronisattion würde ich aber komlett abkoppeln vom "normalen"
                    Betrieb - zumindest auf die Schreibzugriffe verlegen, dass also bei einer Änderung des Zustands
                    einer Datenquelle diese einen Prozess antickt, dass diese Änderungen dann auch in der
                    gemeinsamen Datenbank vollzogen werden.

                    Für den Einsatz fällt mir ohnehin auf Anhieb nichts anderes ein, als entfernte LDAP-Server zur
                    Benutzerverwaltung.

                    Basti

                    Kommentar


                    • #11
                      Meine Gedanken für den Anwendungsbereich gehen in Richtung Data Mining als Grundlage für Reporting und Analyse. Nicht als Grundlage für Business Objects und Cognos Alternativen, aber für die Entwicklung von schmalen BI Lösungen mit Sicherheit nützlich - gerade bei der Entwicklung von Reporting/Monitoring Cockpits.

                      Kommentar


                      • #12
                        Keine Ahnung ob du das ernst oder als Joke meinst, verstanden hab ichs jedenfalls nicht. Mit beiden genannten Interpretationsmöglichkeiten

                        Kommentar

                        Lädt...
                        X