Mit welchen Datenbankkomponenten afangen?

[hoika]

Hallo,
also ich hatte keine Probleme.
Aber jetzt wäre doch Anlass, schnell auf Chrome umzusteigen...

[mkinzler]

DBeaver ist auch nicht schlecht.

[Delphi.Narium]

Wenn's um einfach und mit vorhandenen Delphimitteln gehen soll, dann nimm doch die ADO-Komponenten. Für zumerstmal grundsätzliches Lernen reicht das vollkommen aus.

Damit legt man sich auch nicht direkt auf 'nen bestimmten Datenbanktypen fest. Es kann an Datenbanken quasi alles, wozu es 'nen ODBC-Treiber gibt und was das System sonst so an Datenbanktreibern zur Verfügung stellt.

Ganz einfach ist 'ne Access-Datenbank. Access braucht man dazu natürlich nicht.

Man muss sich über die TADOConnection-Komponente einfach 'ne Verbindungszeichenfolge erstellen, das geht dialoggesteuert und ist nicht so kompliziert, wie es klingt. Wenn man da 'ne Accessdatenbank (Jet-Engine) auswählt, wird man auch gefragt, ob man ggfls. 'ne neue Datenbank haben will. Die wird dann erstellt.

Und für 'ne CD-/DVD-...Verwaltung zu Übungszwecken, reicht das vollkommen aus.

Man braucht keinen Download von was auch immer, keine Registrierung, wo auch immer, keine Installation von was auch immer ...

Einfach Delphi nehmen und machen

[jobo]

"Einfach ADO und gut" find ich gut.
Und Versionskonflikte/-abhängikeiten hat Emba sicher nicht erfunden. Wenn ich auf Java Projekte o.ä. schaue ist es bei Delphi doch recht übersichtlich.
Access ist im Prinzip ok, aber letztlich "Autsch". Single File DB ist natürlich charmant, bei Access gibt's aber so viel Absonderlichkeiten auf SQL und Funktionsseite, dass ich das zwecks "gar nicht erst dran gewöhnen" nicht empfehlen würde.
Single File geht auch gut mit Firebird (embedded), kann problemlos aufgeblasen werden und ist viel näher an den Standards als Access.

DBeaver ist prima, wenn ich mich auch immer wieder wundere, dass mal was funktioniert und mal nicht (Code Completion, ..). Ach prima ist eigentlich untertrieben, eine sehr gute kostenlose und vielseitige DB IDE.

[Delphi.Narium]

Access ist sicherlich nicht so wirklich das Wahre, wenn es um richtig professionelle Software geht oder man richtig viele Daten hat.

Wenn man aus Delphi heraus programmiert und beim Erstellen von Tabellen ... sich an den SQL-Standard hält, dann geht das wunderbar. nimmt man aber die Accessoberfläche und klickt sich da was zusammen, wird es (für meine Begriffe) recht schnell absonderlich.

Aber ein Vorteil ist auch: Wenn man sich beim Üben und Lernen "verzockt" hat, schmeißt man die Datei weg, läßt sich 'ne neue Machen und fängt nochmal an.

Zeit für den Neuanfang: 2 Minuten? Oder weniger?

Zum Lernen und Probieren käme ich nie auf die Idee, mir erstmal 'nen Datenbankserver zu installieren, diverses Komponenten zu kaufen ...

Erstmal nur die "Hausmittel" und die hat man für die Datenbankentwicklung nunmal mit dem Betriebssystem und Delphi alle.

Wenn man den Umgang damit kapiert hat, kann man sich mit wenig Aufwand in die professionellen Werkzeuge einarbeiten und hat auch schon das Knowhow, um eine zielgerichtete Auswahl von Datenbank und Zugriffskomponenten zu treffen.

Zum Schreibenlernen in der Schule brauchten wir keinen Füller von Montblanc mit Goldfeder und Tintenfass, die einfachen von Pelikan mit Patronen taten es auch.

[mkinzler]

Bei SQLite oder FireBird embedded muss man keinen Server installieren.

[Delphi.Narium]

Nein, aber schon wissen, wo die passenden DLLs ... hinmüssen.

Man muss was installieren, was noch nicht auf dem System vorhanden ist.

Und mit reinen Delphihausmitteln und nur Windows ist es da dann eben auch schon nicht mehr gemacht.

ADO und Access u. a. auch wegen

Zitat von vor 'ner Stunde weiter oben:

Man braucht keinen Download von was auch immer, keine Registrierung, wo auch immer, keine Installation von was auch immer ...

[Schokohase]

Zitat von Delphi.Narium:

Man muss was installieren, was noch nicht auf dem System vorhanden ist.

Und mit reinen Delphihausmitteln und nur Windows ist es da dann eben auch schon nicht mehr gemacht.

FireDAC und SQlite => einfach so mit Delphihausmitteln