(Access-)Datenbank-Zugriff ohne Engine

[Bernhard Geyer]

Zitat von Marphy:

Zitat von Bernhard Geyer:

- ist mit (aktuell) ca. 2 MB für 2 DLL's und 2 (oder warens 3) Konfigurationsdateien sehr schlank

Gut, das ist vertretbar. Aber wie läuft das mit der Lizenz ab? Kann man die Programm-Files im eigenen Setup weitergeben?

Ja. Sonst wärs ja als kostenloses Programm sinnlos.

Zitat von Marphy:

Ach ja: Wie wird eigentlich von Delphi aus auf die Datenbank zugegriffen?

Wie mit BDE/ADO auch. Es werden Komponenten in der IDE installiert die fast die gleiche Schnittstelle wie TDatabase/TTabel/TQuery haben.

[Alter Mann]

Hallo,

wie wärs mit SQLite? Die DB ist eine Datei und benötigt eine (1) DLL.

[urs.liska]

Zitat von Marphy:

Hallo Bernhard, hallo Urs,
...

Zitat von urs.liska:

Und natürlich auch mal wieder Firebird

Klingt gut. Können bei diesem DB-System access-ähnlich mehrere Tabellen zu einer Datei zusammengefasst werden?

Eine Firebird-Datenbank ist im Normalfall eine einzelne Datei, die alle Elemente beinhaltet. Nicht "access-ähnlich" ist Firebird in der Hinsicht, dass es sich um einen ausgewachsenen SQL-Server handelt.

Und nochmals zum Delphi-Zugriff auf so eine Datenbank:
Es gibt eine Reihe von Komponentensammlungen, mit denen man das realisieren kann.
Alle greifen direkt auf das Firebird-API zu, so dass keine Sachen wie BDE oder ODBC vorhanden sein müssen.
Zwei OpenSource-Sammlungen gibt es: "Unified Interbase" und "ZEOS-Lib".
Außerdem gibt es zwei kommerzielle Pakete: FIBPlus und IBObjects. Bei beiden muss man als Entwickler eine Lizenz erwerben, kann das Programm aber ohne Gebühren weitergeben. IBObjects bietet darüber hinaus auch an, sich um eine kostenlose Lizenz zu bewerben, solange man mit den damit erstellten Programmen kein Geld verdient (sehr nett, nicht?).
In allen Fällen braucht man mindestens Delphi Professional, wenn man mit den datensensitiven Steuerelementen arbeiten will.
IBObjects liefert allerdings auch eine Menge eigener visueller Komponenten mit, so dass man auch mit Delphi Personal arbeiten könnte (man hat sich dann aber von Drittanbietern abgeschnitten).


HTH
Urs

[Robert_G]

Zitat von Marphy:

• Mehrere Tabellen und große Datenmengen (> 1 GB) sollen (ggf. komprimiert) in einer einzigen Datei zusammengefasst werden.

Du wolltest 1GB in eine Jet-DB stecken?
btw: Firebird steckt 1GB einfach so weg.

Zitat von Marphy:

• Hohe Performance (> 50.000 Einträge).

Das bezweifle ich ernsthaft.
Die einzigen Situationen in denen ich eine so große Anzahl Datensätze abgefragt habe waren Exports oder Replikationen.

Zitat von Marphy:

• DB ist lokal (d.h. keine komplizierten Netzwerkzugriffe, die DB wird quasi "nur" als "Datenfile" benutzt).

Das schließt schon vom Konzept mehrere Benutzer aus. (Kommt mir bitte nicht damit, dass man auch lokale DBs im Mehrbenutzerbetrieb fahren "könnte" )

Zitat von Marphy:

• Das ganze System sollte möglichst schlank sein!

Firebird!

Zitat von urs.liska:

Sehr gut skalierbar, vom kleinsten Einzelplatzprojekt bis zum großen Firmennetzwerk.

Firebird mag ganz cool sein, aber er ist nicht wirklich skalierbar.
Du kannst Tabellen nicht partitionieren oder Inidizes, Daten und Temp auf unterschiedliche Platten lagern.
Natürlich gibt es auch keinen Parallel server modus, das wäre nämlich wirkliche Skalierbarkeit.
Wenn du damit Mehrprozessorsysteme meinst: Ja klar, dadurch ist eine gewisse Skalierbarkeit gewährleistet.

Versteht mich nicht falsch: Für einen Ersatz zu Jet ist FB natürlich wie ein Lotus Esprit verglichen mit einem Trabi.

[urs.liska]

Zitat von Robert_G:

Zitat von urs.liska:

Sehr gut skalierbar, vom kleinsten Einzelplatzprojekt bis zum großen Firmennetzwerk.

Firebird mag ganz cool sein, aber er ist nicht wirklich skalierbar.
Du kannst Tabellen nicht partitionieren oder Inidizes, Daten und Temp auf unterschiedliche Platten lagern.
Natürlich gibt es auch keinen Parallel server modus, das wäre nämlich wirkliche Skalierbarkeit.
Wenn du damit Mehrprozessorsysteme meinst: Ja klar, dadurch ist eine gewisse Skalierbarkeit gewährleistet.

Es mag sein, dass ich hier über etwas geschrieben habe, das ich nicht wirklich verstehe. Ich habe letztlich nur den Eindruck wiedergegeben, den ich von einer kürzlichen Diskussion auf der Firebird-support-Mailingliste erhalten habe.
Der Begriff "Skalierbarkeit" scheint mir aber auch i.A. etwas mehrdeutig verwendet zu werden.
Was ich meinte, war – sicherlich nicht ganz korrekt im Gebrauch des Wortes –: Firebird kann in ausgesprochen verschieden dimensionierten Anwendungen zum Einsatz kommen.
Neben der geannten DPA sowie diversen Universitäten wurde in dieser Diskussion auch der Fall einer amerikanischen Telefongesellschaft beschrieben, die alle Telefonatdaten mit Firebird speichert. Dabei kommen hunderttausende von Transaktionen pro Stunde zusammen, und es können für jeden Kunden bis zu sechs Jahren zurückliegende Rechnungen erstellt werden. Derjenige, der diese Datenbank betreut, führte ins Feld, dass der Schlüssel zur "Skalierbarkeit" das Datenbankdesign sei und erst in zweiter Linie die verwendete Soft- und Hardware.

Was ich damit letztlich nur zum Ausdruck bringen wollte, war, dass Firebird für den gewünschten Zweck mit Sicherheit gerüstet ist (und gleichzeitig keine Komplikationen verursacht, wenn man ihn als Entwickler auf seinem schnöden kleinen Einzelplatz laufen hat...

MfG
Urs

[Luckie]

Also wenn ich eine Microsoft Access Datenbank ansprechen sollte, gerade dann wäre meine erste Wahl Visual Basic, denn gerade im Zusammenspiel mit Anwendungen aus dem eigenen Haus fällt vieles mit Visual Basic leichter.

[Leuselator]

Abtrünniger - man schmeisse den Purschen Zu Poden!

[urs.liska]

Zitat von Leuselator:

Abtrünniger - man schmeisse den Purschen Zu Poden!

Nur weil er die heilige Inkontinentia nicht ausgelacht hat???