Announcement

Collapse
No announcement yet.

DB-Connectivity - was kommt nach der BDE ??

Collapse
X
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    DB-Connectivity - was kommt nach der BDE ??

    Hallo zusammen,<br><br>

    nachdem ich erfahren habe, daß die BDE nicht weiterentwickelt wird <br>
    drängt sich bei mir die Frage auf, welche Art des Datenbankzugriffs<br> für z.B. Delphi 6 erstellte Anwendungen nun zu empfehlen ist ?<br><br>

    Mein Ziel wäre eine performante C/S-Anwendung für Zugriffe auf Oracle<br> (8 bzw. 9i) eventuell parallel auch auf Interbase.<br><br>

    Nachdem meine unter Delphi 5 erstellte Anwendung zuverlässig über die BDE zugreift,<br>
    frage ich mich nun, ob ich DBExpress oder ADO-Komponenten oder einer ganz anderen <br>Technik den Vorzug geben soll ?<br><br>
    Es wäre natürlich schön, wenn ich meine TQUERY/TTABLE-Komponenten ohne zeitraubendes<br> Umprogrammieren weiterverwenden könnte. <br><br>

    Kann mir jemand einen zukunftsweisenden Tip geben ? - vielen Dank<br><br>

    Gruß Joerg.<br>
    Tags: None
  • #2
    Soll der Zugriff hauptsächlich nur auf Oracle gehen, so sind hier native-Komponenten wie z.B. von http://www.allroundautomations.com angesagt (Direct Oracle Access). Die o.g. Komponenten haben fast die gleichen Schnittstellen (Methoden, Properties) wie die TQuery/TTable-Komponenten.

    Für Interbase gibt es ebenfalls native Komponenten.

    Sollen mehrere Datenbanken unterstützt werden, für die es keinen gemeinsamen zuverlässigen Zugriffsweg (wie z.B. ADO für MS-SQL, Access) gibt, so sollte man sich eine eigene Abstraktionsschicht entwickeln (Stichwort: Bridge-Pattern), welche die Eigenheiten der Datenbankschnittstellen kapselt) und es trotzdem ermöglicht auf jeder Datenbank letztendlich "native" zuzugreifen (ADO für Access und MS-SQL, BDE für Paradox und dBase, ...

    Comment

    • #3
      <html>
      <head>
      <title></title>
      Vielen Dank für die schnelle Antwort,<br><br>

      eigentlich suche ich nach einer Möglichkeit meine C/S-Applikation
      mit all den netten Features die heutzutage Standard sind (z.B. Neusortierung
      im DBGrid bei Doppel-Klick auf den Spaltenkopf, bi-direktionales Scrollen, etc.)
      möglichst <b><i>unabhängig</b></i> von der darunterliegenden Datenbank zu entwickeln.
      Ideal wäre eine abstrakte Connectivity-Schicht, die es zuläßt zwischen
      verschiedenen Datenbanksystemen zu wechseln <b><i>ohne die Datensteuerungskomponenten verändern zu müssen</b></i>.

      Im Moment tendiere ich zu einer Kombination aus:<br><br>
      <b>dbExpress</b> + <b>DataSetProvider-</b> + <b>ClientDataSet</b>-Komponenten.<br><br>

      Wenn ich das ganze richtig verstehe, dann gestattet mir dbExpress Zugriff auf
      die nativen Netzwerk-Schichten des jeweiligen Datenbankherstellers - ich komme
      also gänzlich ohne BDE oder ODBC aus und da es sich um eine herstellerspezifische
      Zugriffsschicht handelt, glaube ich damit eine performante Lösung zu haben.

      Den Nachteil unidirektionaler Datenmengen kann ich wohl mit ClientDataSet ausgleichen, indem lokal in der Datenmenge navigiert und sortiert wird - das klingt ebenfalls nach
      guter Performance bei gleichzeiter Plattformunabhängigkeit - so weit - so gut.
      <br>
      Einziger Wehrmutstropfen scheint die Tatsache zu sein, daß sich dieses Modell für
      Master/Detail-Zugriffe nicht eignet(hab ich jedenfalls gelesen) - ist dem so ?
      und wenn ja, welche Alternativen habe ich eine Master/Detail-Komponente zu implementieren, wenn ich bei dbExpress+ClientDataSet bleiben will ? Liege ich mit meiner Einschätzung zu
      dbExpress + ClientDataSet überhaupt richtig (Ziel wäre also größtmögliche Portierbarkeit
      bei gleichzeitig minimaler Notwendigkeit die Sourcen verändern zu müssen).

      Bin für jeden Tip wirklich dankbar<br><br>
      Schönen Gruß - Joerg.<br>

      </head>
      <body text="#000000" bgcolor="#FFFFFF" link="#FF0000" alink="#FF0000" vlink="#FF0000">

      </body>
      </htm

      Comment

      • #4
        <html>
        <head>
        <title></title>
        Vielen Dank für die schnelle Antwort,<br><br>

        eigentlich suche ich nach einer Möglichkeit meine C/S-Applikation
        mit all den netten Features die heutzutage Standard sind (z.B. Neusortierung
        im DBGrid bei Doppel-Klick auf den Spaltenkopf, bi-direktionales Scrollen, etc.)
        möglichst <b><i>unabhängig</b></i> von der darunterliegenden Datenbank zu entwickeln.
        Ideal wäre eine abstrakte Connectivity-Schicht, die es zuläßt zwischen
        verschiedenen Datenbanksystemen zu wechseln <b><i>ohne die Datensteuerungskomponenten verändern zu müssen</b></i>.

        Im Moment tendiere ich zu einer Kombination aus:<br><br>
        <b>dbExpress</b> + <b>DataSetProvider-</b> + <b>ClientDataSet</b>-Komponenten.<br><br>

        Wenn ich das ganze richtig verstehe, dann gestattet mir dbExpress Zugriff auf
        die nativen Netzwerk-Schichten des jeweiligen Datenbankherstellers - ich komme
        also gänzlich ohne BDE oder ODBC aus und da es sich um eine herstellerspezifische
        Zugriffsschicht handelt, glaube ich damit eine performante Lösung zu haben.

        Den Nachteil unidirektionaler Datenmengen kann ich wohl mit ClientDataSet ausgleichen, indem lokal in der Datenmenge navigiert und sortiert wird - das klingt ebenfalls nach
        guter Performance bei gleichzeiter Plattformunabhängigkeit - so weit - so gut.
        <br>
        Einziger Wehrmutstropfen scheint die Tatsache zu sein, daß sich dieses Modell für
        Master/Detail-Zugriffe nicht eignet(hab ich jedenfalls gelesen) - ist dem so ?
        und wenn ja, welche Alternativen habe ich eine Master/Detail-Komponente zu implementieren, wenn ich bei dbExpress+ClientDataSet bleiben will ? Liege ich mit meiner Einschätzung zu
        dbExpress + ClientDataSet überhaupt richtig (Ziel wäre also größtmögliche Portierbarkeit
        bei gleichzeitig minimaler Notwendigkeit die Sourcen verändern zu müssen).

        Bin für jeden Tip wirklich dankbar<br><br>
        Schönen Gruß - Joerg.<br>

        </body>
        </htm

        Comment

        • #5
          Vielen Dank für die schnelle Antwort<br><br>

          eigentlich suche nach einer Möglichkeit eine C/S-Applikation mit all den netten Features die heutzutage Standard sind (z.B. Neusortierung im DBGrid bei Doppel-Klick auf den Spaltenkopf, bi-direktionales Scrollen, etc.) möglichst <b><i>unabhängig</b></i> von der darunterliegenden Datenbank zu entwickeln. Ideal wäre eine abstrakte Connectivity-Schicht, die es zuläßt zwischen verschiedenen Datenbanksystemen zu wechseln <b><i>ohne die Datensteuerungskomponenten verändern zu müssen</b></i>.

          Im Moment tendiere ich zu einer Kombination aus:<br><br>
          <b>dbExpress</b> + <b>DataSetProvider-</b> + <b>ClientDataSet</b>-Komponenten.<br><br>

          Wenn ich das ganze richtig verstehe, dann gestattet mir dbExpress Zugriff auf
          die nativen Netzwerk-Schichten des jeweiligen Datenbankherstellers - ich komme
          also gänzlich ohne BDE oder ODBC aus und da es sich um eine herstellerspezifische
          Zugriffsschicht handelt, glaube ich damit eine performante Lösung zu haben.

          Den Nachteil unidirektionaler Datenmengen kann ich wohl mit ClientDataSet ausgleichen, indem lokal in der Datenmenge navigiert und sortiert wird - das klingt ebenfalls nach
          guter Performance bei gleichzeiter Plattformunabhängigkeit - so weit - so gut.
          <br>
          Einziger Wehrmutstropfen scheint die Tatsache zu sein, daß sich dieses Modell für
          Master/Detail-Zugriffe nicht eignet(hab ich jedenfalls gelesen) - ist dem so ?
          und wenn ja, welche Alternativen habe ich eine Master/Detail-Komponente zu implementieren, wenn ich bei dbExpress+ClientDataSet bleiben will ? Liege ich mit meiner Einschätzung zu
          dbExpress + ClientDataSet überhaupt richtig (Ziel wäre also größtmögliche Portierbarkeit
          bei gleichzeitig minimaler Notwendigkeit die Sourcen verändern zu müssen).

          Bin für jeden Tip wirklich dankbar<br><br>
          Schönen Gruß - Joerg.<br>

          </body>
          </html&gt

          Comment

          • #6
            Hallo,

            &gt;..glaube ich damit eine performante Lösung zu haben.

            wie praktische Versuche zeigen, ist die Kombination von dbExpress + ClientDataSet fast um den Faktor 5..10 langsamer als die anderen nativen datenbankspezifischen Zugriffswege (IBX oder ADO). Wie der zweite Vergleich zwischen TClientDataSet und dem nativen Recordset-Objekt von ADO zeigt, ist TClientDataSet für den Performance-Einbruch verantwortlich (von den MemoryLeaks von TClientDataSet einmal abgesehen).

            &gt;Bin für jeden Tip wirklich dankbar

            Die Frage wurde zu einem denkbar ungünstigen Zeitpunkt gestellt :-)

            Delphi befindet sich zur Zeit im Umbruch in die neue .NET-Welt, dies wird auch gravierende Auswirkungen auf die Datenbankschicht haben. Denn mit ADO.NET und der DataSet-Klasse ist ein so starker Gegner vorhanden (mehrer Ergebnismengen in einem DataSet, Relationen und Constraints werden unterstützt usw.), das die Delphi-spezifischen Lösungen ein Nischendasein fristen werden (wenn der absehbare Wechsel zu .NET tatsächlich so erfolgt wie angekündigt)

            Comment

            • #7
              # Joerg

              Selbstverständlich kann man mit ClientDataSet auch Master/Detail Verknüpfungen bearbeiten. Es gibt sogar zwei Methoden: Nested DataSets oder die übliche Verknüpfung wie bei TTable.

              Ein Performanceverlust konnte ich nicht feststellen. (Ich verwende InterBase mit SQL-Links).
              Im Gegenteil: Transaktionen sind nur sehr kurz offen. Die Sortiermöglichkeiten auf Clientseite sind extrem schnell und flexibel. ClientDataSet bietet noch viele weitere Features: Aggregate, CloneCursor, usw. usw.

              Leider gibt Andreas nicht an, welche Zugriffskomponenten er verwendet hat. Evtl. liegt es an dbExpress von Delphi 6. Hier heisst es: Hoffen auf Delphi 7

              Comment

              • #8
                > wie praktische Versuche zeigen, ist die Kombination von dbExpress + ClientDataSet fast um den Faktor 5..10 ...

                Da habe ich andere Erfahrungen.

                Okay, wenn man eine große Tabelle hat, bei dbExpress alle Datensätze nach TClientDataSet fetcht und dagegen bei IBX nur so viele Datensätze, wie dbGrid anzeigt, dann wird das nun mal Größenordnungen länger dauern. Das ist aber kein fairer Vergleich, und mit PacketRecords kann man da auch anders vorgehen.

                Und wenn es um den Vergleich geht, große Datenmengen komplett zu übertragen (Listendruck von einigen tausend Adressen), dann ist dbExpress ein ganzes Stück schneller, und zwar sowohl mit TClientDataSet als auch ohne

                Comment

                • #9
                  Hallo,

                  &gt;..Da habe ich andere Erfahrungen...

                  ich halte mich an das <i>Winston Churchill</i> zugeschriebene Sprichwort: "Vertraue nur einer Statistik, die Du selbst gefälschst hast" :-)

                  In meiner ADO- und IBX-Session der Entwickler-Konferenzen der letzten Jahre stelle ich u.a. ein Testprogramm vor, dass die Zugriffswege von BDE, ADO, dbGo (ADO Express), IBX und dbExpress für typische Aufgaben (SELECT, INSERT, UPDATE sowohl für einzelne Datensätze als auch für Ergebnismengen) miteinander vergleicht. In allen Kategorieren bilden die dbExpress-Komponenten das Schlusslicht, wobei ich alle offiziellen (d.h. dokumentierten) Optimierungskonfigurationen der verschiedenen Komponenten und der Datenbank (Stored Procedure) nutze. Zum Beispiel ist sogar der schnellste BDE-Weg um einen Tick performanter als der schnellste dbExpress-Weg. Immer dann, wenn TClientDataSet im Spiel genutzt wird, ist das Rennen schon beim Start verloren :-

                  Comment

                  Previous template Next
                  Working...
                  X