ADO oder DBX mit Delphi

Question

Welches ist besser (und aus welchen Gründen), um eine Verbindung zu MS SQL, Oracle oder Firebird aus einer Delphi Win32-Anwendung zu erstellen - ADO oder DBX (Database Express)?

Beide ermöglichen die Verbindung mit den wichtigsten Datenbanken. Ich mag die Art, wie ADO alles mit einer Änderung der Verbindungszeichenfolge und der Tatsache, dass ADO und die Treiber in Windows enthalten sind, so dass nichts extra zu implementieren ist (es scheint, korrigiere mich, wenn ich falsch liege).

DBX ist auch flexibel und ich kann die Treiber in meine App kompilieren, kann ich nicht?

Ich bin wirklich scharf auf eine einzige Quelle, wenn möglich, mit der Möglichkeit, Datenbanken abhängig von der IT-Abteilung/Präferenzen des Kunden zu variieren.

Aber was ist einfacher zu programmieren, führt besser aus, verwendet Speicher am effizientesten? Irgendwelche anderen Dinge, um sie zu unterscheiden?

Dank, Richard

Answer 1

ADO ist einfach zu bedienen, und es gibt, man muss nur sicherstellen, dass die Korrespondenz-Client-Treiber in der Client-Seite zu installieren.

Ich fand DBX flexibler und es ist besser in IDE und anderen Technologien wie DataSnap integriert.

Zum gleichen Zweck wie Sie, habe ich DBX mit Third-Party-Treiber von DevArt verwendet. Sie können die Treiber mit Ihrer Anwendung kompilieren, wenn Sie die Treiberquellen kaufen.

Answer 2

Allgemeine Regel: Jede Schicht von Komponenten wird möglicherweise eine zusätzliche Schicht von Fehlern hinzufügen. Sowohl ADO als auch DBX sind Komponentenumhüllungen um die Standarddatenbankfunktionalität und sind daher beide gleich stark. Also sollte die richtige Wahl auf anderen Faktoren basieren, wie den Datenbanken, die Sie verwenden möchten. Wenn Sie eine Verbindung zu MS-Access oder SQL Server herstellen möchten, ist ADO die bessere Wahl, da es für diese Datenbanken nativer ist. Aber Firebird und Oracle sind nativer für die DBX-Komponenten.

Ich persönlich tendiere dazu, die rohen ADO-APIs zu verwenden. Andererseits verwende ich in meinen Projekten keine datensensitiven Komponenten. Es ist weniger RAD, ich weiß. Aber ich muss oft auf diese Weise arbeiten, weil ich Client/Server-Anwendungen mit mehreren Ebenen zwischen der Datenbank und der GUI schreibe, was die Sache komplizierter macht.

Answer 3

ADO ist Microsoft Welt

DBX wurde am Anfang (Delphi 6) für Cross-Plattform und Kylix

Answer 4

Meine zwei Cent erstellt: DBX deutlich schneller ist (sowohl auf Oracle und SQL), und deutlich mehr knifflig und schwieriger zu implementieren.

Wenn Leistung ein Faktor ist, würde ich mit DBX gehen. Ansonsten würde ich einfach ADO verwenden.

Answer 5

Wie andere gesagt haben, kann DBX in bestimmten Fällen oder unter bestimmten Umständen die Spitzenleistung erbringen, aber ADO ist die Grundlage für eine sehr große Anzahl von Anwendungen in der Welt, obwohl die Leistung von ADO relativ schlechter sein kann. klar, das heißt nicht "inakzeptabel" arm.

Für mich selbst, und informiert von großen Projekten, an denen ich gearbeitet habe, ist das größte "Problem" mit DBX, dass es, egal wie gut es ist, eine Schlüsselinfrastrukturtechnologie von einem Sprach-/Werkzeugunternehmen ist.

Jeder, der Anwendungen auf der vorherigen BDE-Technologie erstellt hat, wird auf die Störung hinweisen, die verursacht wird, wenn diese Technologie veraltet ist und nicht mehr unterstützt wird. Während keine Technologie gegen die Abwertung durch ihren Provider immun ist, hat ADO eindeutig die Nase vorn, wenn es um die Unterstützung der Industrie geht, die über den Technologieanbieter selbst hinausgeht.

Aus diesem Grund verwende ich selbst jetzt immer ADO. Es muss jedoch nicht immer nur die Verbindungszeichenfolge geändert werden, wenn Sie von einem Datenbanktyp zu einem anderen wechseln. Die Aufrufsyntax für gespeicherte Prozeduren kann von einem ADO-Anbieter zu einem anderen variieren, und Sie müssen immer noch die von Ihnen verwendete SQL-Syntax überwachen, wenn Sie eine Bereitstellung für mehrere verschiedene SQL-Engines planen, wobei die SQL-Unterstützung variieren kann.

Um diese Probleme zu verringern, verwende ich meine eigene Kapselung des ADO-Objektmodells. Diese Einkapselung versucht nicht, das Objektmodell in etwas zu verwandeln, das ADO nicht ähnelt, es legt einfach die Teile von ADO offen, die ich direkt in einem objektpascalfreundlichen (und typsicher) Formular verwenden muss (z. B. Aufzählungstypen und setzt für Konstanten und Flags usw. statt nur Werte, wenn nicht Hunderte von ganzzahligen Konstanten).

Meine Einkapselung kümmert sich auch um einige der geringfügigen Abweichungen in verschiedenen Anbieterverhalten/Anforderungen, wie die zuvor erwähnten Unterschiede in der Aufrufsyntax für gespeicherte Prozeduren.

Ich sollte auch sagen, dass ähnlich wie bei einem anderen Plakat, ich vor langer Zeit verwendet "Daten bewusst Kontrollen", die diesen Ansatz eröffnet. Wenn Sie datensensitive Steuerelemente verwenden möchten oder möchten und ADO verwenden möchten, können Sie ADO nicht direkt verwenden und müssen stattdessen eine Kapselung finden, die ADO durch das VCL-Datasetmodell verfügbar macht.

Answer 6

Am Anfang von Delphi lobten die Leute die Multi-DBMS-Unterstützung in Delphi. Jeder liebte die BDE (weil das der einzige Weg war, das zu tun).

Aber wenn ich Kunden über mehr als das letzte Jahrzehnt betrachte, habe ich einen stetigen Rückgang der Multi-DBMS-Unterstützung in ihren Anwendungen gesehen.

Die Kosten für die Unterstützung mehrerer DBMS aus einer Anwendung sind hoch.

Nicht nur, weil Sie Kenntnisse über jedes DBMS haben müssen, sondern auch, weil jedes DBMS seine eigenen Besonderheiten hat, an die Sie sich in Ihrer Datenzugriffsschicht anpassen müssen. Dazu gehören nicht nur Syntaxunterschiede und zugrunde liegende Datentypen, sondern auch Optimierungsstrategien.

Auch einige DBMS funktionieren besser mit ADO, einige besser mit einer direkten Verbindung (wie überspringen Sie Ihren Oracle-Client alle zusammen).

Schließlich ist das Testen aller Kombinationen Ihrer Software mit mehreren DBMS-Systemen sehr intensiv.

Ich war an einigen Projekten beteiligt, bei denen wir das DBMS-Backend und/oder die Datenzugriffstechnologie (von z. B. BDE zu DBX oder von DBX zu einer direkten Verbindung) ändern mussten. Das Ändern des Backends war immer viel schmerzhafter als das Ändern der Datenzugriffstechnologie. Mehrstufige Ansätze machten sie etwas einfacher, erhöhten aber die Freiheitsgrade und damit die Testanstrengungen.

Einige der Produkte, die ich sehe, die Multi-DBMS unterstützen, sind in vertikalen Marktanwendungen, wo der Endkunde bereits seine eigene DBMS-Infrastruktur hat und die Anwendung sich darauf einstellen muss. In niederländischen Regierungsbereichen beispielsweise war Oracle sehr stark, aber SQL Server hat auch eine recht große Benutzerbasis geschaffen.

Sie müssen also überlegen, welche Kombinationen von DBMS Sie nicht nur hinsichtlich der Funktionalität, sondern auch hinsichtlich der Kosten unterstützen möchten.

Wenn Sie bei einem DBMS bleiben, dann macht es keinen Sinn, sich für eine generische Datenzugriffsschicht wie BDE, DBX oder ADO zu entscheiden: es zahlt sich aus, eine Verbindung so direkt wie möglich zu machen. Meine Erfahrung hat mich gelehrt, dass diese Kombinationen gut funktionieren:

• Interbase oder Firebird mit FIBPlus, AnyDAC, IBO oder IBX *
• Oracle mit AnyDAC, DOA oder ODAC

• Microsoft SQL Server mit ADO

  • IBX mag Fi nicht rebird sehr viel.

Hoffnung, das gibt Ihnen einen Einblick in die Möglichkeiten und Grenzen von mehreren DBMS von Delphi-Anwendungen unterstützt.

--jeroen