SQL only Dantenbank erstellen ?

[BBoy]

Ich habe schon ein paar mal das Problem gehabt das ich eine DB mit irgendwelchen Komponenten programmiert hatte die später dann Geld kosteten oder einfach nicht weiter entwickelt wurden und so dann in einer neuen Delphi version nicht mehr funktionierten. Bin derzeit bei ABS-Database, damit funktioniert alles recht einfach. Speichert aber auch wieder in speziellem Format .abs und genau das möchte ich nicht.
Ich programmiere nur kleine, einfache Datenbanken für den Heimgebrauch. Daher kommt ein SQL-Server nicht in Frage.

Kann man irgendwie eine SQL-Datenbank erstellen ohne Server und ohne Komponenten die das dann wieder in einem speziellen Format speichern (*.abs)? Also das eine reine .sql Datei die ich auch in vielen Jahrzehnten noch nutzen kann? Ich verwende allerdings auch Master- und Detailtables, das sollte in SQL auch funktionieren.
Leider ist mein Wissen recht oberflächlich (reicht aber für meine Zwecke), von daher wären Komponenten die mir den Umgang etwas erleichtern von Vorteil.

[Uwe Raabe]

SQL ist eine Abfragesprache und kein Datenbankformat. Insofern macht deine Frage keinen Sinn.

[mkinzler]

Du legst also keinen Wert auf "customized Tools", die Tools müssen halt nur an deine Bedürfnisse angepasst sein :wink:
Irgendwie widerspricht dich deine Aussage.
Du solltest dein Wissen mal etwas vertiefen.
Btw. es gibt auch embedded Lösungen ohne extra Server.

[BBoy]

OK, neuer Versuch:

Ich kann mit SQL Datenbanken anlegen, verändern usw.
Für die meisten Lösungen benötigt man dazu aber einen SQL-Server.
Benötige nur ICH den Server zum erstellen oder auch der Anwender der dann diese DB bzw. mein Programm nutzt?

Wenn auch der Anwender einen SQL-Server benötigt, dann ist das für mich uninteressant und ich benötige eine Embedded Version. So das der Anwender des Programms ohne Server installation auskommt.

Egal wie, die Datendatei sollte in einem Format gespeichert werden, dass ich jederzeit problemlos wieder mit sql auslesen kann und nicht ein spezielles datenformat wie zb. Absolute Database wo die Daten in eine .abs datei schreibt. Die dann auch nur von ABS-Database gelesen werden kann.

Ziel ist es, eine Datenbankdatei zu haben die man mit jeder beliebigen (sql)Datenbankkomponente lesen und bearbeiten kann.

Hoffe es ist nun besser verständlich auf was es mir ankommt :)

[mkinzler]

Zitat:

Benötige nur ICH den Server zum erstellen oder auch der Anwender der dann diese DB bzw. mein Programm nutzt?

Ja. Bei embedded-Lösungen ist dies aber kein eigenständiges Programm.

Zitat:

Egal wie, die Datendatei sollte in einem Format gespeichert werden, dass ich jederzeit problemlos wieder mit sql auslesen kann und nicht ein spezielles datenformat wie zb. Absolute Database wo die Daten in eine .abs datei schreibt. Die dann auch nur von ABS-Database gelesen werden kann.

Es gibt aber kein allgemeines Format von SQL! (Was Uwe ja schon schrieb).
Du müsstest die Daten also in einem neutralen Format (XML, CSV, INI) ablegen, dich dann aber selber um die Funktionalitäten des DB-Servers kümmern. Das macht aus meiner Warte absolut keinen Sinn!

[BBoy]

ok, also kann ich das vergessen endlich eine datendatei zu haben die ich jederzeit nutzen kann auch wenn es die Komponente wie z.B. Absolute Database nicht mehr gibt ?
Kann ich kaum glauben... aber wenn ihr das sagt, wird es wohl so sein. Schade.

Kennt wer eine sql embedded database die kostenlos ist und wovon man ausgehen kann das es die lange gibt?

[Union]

Die könntest Clientdatasets im XML Format verwenden.

[Sir Rufo]

Zitat:

Zitat von BBoy (Beitrag 1223807)

ok, also kann ich das vergessen endlich eine datendatei zu haben die ich jederzeit nutzen kann auch wenn es die Komponente wie z.B. Absolute Database nicht mehr gibt ?
Kann ich kaum glauben... aber wenn ihr das sagt, wird es wohl so sein. Schade.

Kennt wer eine sql embedded database die kostenlos ist und wovon man ausgehen kann das es die lange gibt?

In einer schnellebigen Welt von einem komplexen Format wie einer Datenbank zu erwarten, diese bis zum Ende aller Tage nutzen zu können, weil dieses immer supported wird ... den Support wirst du selber übernehmen müssen.

An deiner Stelle würde ich die Anforderung nochmal überdenken

Zitat:

Zitat von Union (Beitrag 1223809)

Die könntest Clientdatasets im XML Format verwenden.

Nicht so wirklich SQL

[bernerbaer]

Hast Du Uwes [nach dem roten Kasten] une mkinzlers Beitrag verstanden? SQL ist kein Dateiformat, es ist eine reine Abfragesprache, evtl hilft dir Wikipedia das verständlich zu machen.
Du benötigst immer einen Datenbank Server, der immer ein eigene Speicherverwaltung für die Daten aufweist. Mit einem geschätzten Zehnzeiler, kannst Du aber jederzeit die Daten in ein für alle Datenbanksysteme verständliches Format exportieren, zb XML, oder CSV, ... welches dann im neuen Datenbanksystem importiert werden kann.

[Sir Rufo]

Zitat:

Zitat von bernerbaer (Beitrag 1223812)

Hast Du Uwes [nach dem roten Kasten] une mkinzlers Beitrag verstanden? SQL ist kein Dateiformat, es ist eine reine Abfragesprache, evtl hilft dir Wikipedia das verständlich zu machen.
Du benötigst immer einen Datenbank Server, der immer ein eigene Speicherverwaltung für die Daten aufweist. Mit einem geschätzten Zehnzeiler, kannst Du aber jederzeit die Daten in ein für alle Datenbanksysteme verständliches Format exportieren, zb XML, oder CSV, ... welches dann im neuen Datenbanksystem importiert werden kann.

Hmmm, MS-Access hat keinen Server

[mkinzler]

Zitat:

Hmmm, MS-Access hat keinen Server

Wenn man Server als Synonym für ein DBMS sieht schon (JET)

Zitat:

Kennt wer eine sql embedded database die kostenlos ist und wovon man ausgehen kann das es die lange gibt?

FireBird (embedded ) und SQLite sind beide OpenSource. Aber eine Garantie, dass die Entwicklung nicht eingestellt wird, kann dir keiner geben.

[BBoy]

ok, dann hat sich das erledigt.
Ist halt ärgerlich wenn man alte Projekte nicht mehr ohne großen Aufwand ändern kann und das nur weil es die verwendete Datenbank nicht mehr gibt. Man will einfach nur ein Buttonklick ändern aber zuvor muss man eine neue DB suchen und alles umprogrammieren.... da die alte DB unter dem neuen Delphi nicht funktioniert.... :oops:
ok was solls......

Würde ich nicht master- Sourcetables nutzen würde mir XML ausreichen.

Muss ich wohl eine embedded finden wo man davon ausgehen kann das es diese ein paar Jahre geben wird.

Dennoch danke für eure Hilfe.....

[mkinzler]

Zitat:

Muss ich wohl eine embedded finden wo man davon ausgehen kann das es diese ein paar Jahre geben wird.

Das ist bei den genannten sehr wahrscheinlich

[khh]

Zitat:

Zitat von Sir Rufo (Beitrag 1223815)

Hmmm, MS-Access hat keinen Server

Scherz ;-)

[Medium]

Wenn man es einigermaßen richtig anstellt, z.B. von vorne herein so entwickelt, dass das benutzte DBMS (weitgehend) beliebig ist, entledigt man sich schon mal den größten Problemen beim Ändern der DB Schicht. Die meisten Delphi DB Komponenten nutzen zudem ein zumindest recht ähnliches Interface, so dass selbst ein Wechsel dieser im aller schlimmsten Fall zumindest machbar wäre. Man sollte nur tunlichst vermeiden einen spezifischen SQL Dialekt eines DBMS zu benutzen, und entweder sich ganz auf die Abstraktionen durch die Komponenten stützen, oder ganz simple Standard-Queries. Die aber auch eher nur im Notfall. Ideal ist, wenn im eigenen Quellcode kein Wort SQL Code steht. (In der Realität selten erreichbar, aber der Versuch lohnt sich meist schon.)
Um Backups der Daten einer DB in ein Textformat (wie vorgenannt z.B. XML oder CSV) kommt jedoch einfach niemand herum. Rate mal, warum DB Backups so ein wichtiges und vielbeachtetes Thema sind.

[mkinzler]

Dann beschränkt man sich aber auf den gemeinsamsten Nenner. Das ist ja wie mit einem Porsche höchstens 80 Fahren :stupid:

[Sir Rufo]

Zitat:

Zitat von BBoy (Beitrag 1223820)

ok, dann hat sich das erledigt.
Ist halt ärgerlich wenn man alte Projekte nicht mehr ohne großen Aufwand ändern kann und das nur weil es die verwendete Datenbank nicht mehr gibt. Man will einfach nur ein Buttonklick ändern aber zuvor muss man eine neue DB suchen und alles umprogrammieren.... da die alte DB unter dem neuen Delphi nicht funktioniert.... :oops:
ok was solls......

Würde ich nicht master- Sourcetables nutzen würde mir XML ausreichen.

Muss ich wohl eine embedded finden wo man davon ausgehen kann das es diese ein paar Jahre geben wird.

Dennoch danke für eure Hilfe.....

Vorbeugend sollte man

• Das alte Entwicklungssystem nicht entsorgen (Virtualisierung)
• Den konkreten Zugriff auf die DB in einem separaten Layer legen, dann ist der Austausch einfacher zu bewerkstelligen

[p80286]

Zitat:

Zitat von BBoy (Beitrag 1223820)

ok, dann hat sich das erledigt.
Ist halt ärgerlich wenn man alte Projekte nicht mehr ohne großen Aufwand ändern kann und das nur weil es die verwendete Datenbank nicht mehr gibt. Man will einfach nur ein Buttonklick ändern aber zuvor muss man eine neue DB suchen und alles umprogrammieren.... da die alte DB unter dem neuen Delphi nicht funktioniert.... :oops:
ok was solls......

So ein Quark, Entschuldigung da platzt mir der Kragen. Ich habe in den letzten Jahren mehrere Male die Zugriffskomponenten für DB wechseln müssen. Gleichzeitig haben sich die darüber angesprochenen Datenbanken geändert. Das war alles keine große Sache.
Du hast z.B. Deine DB-Schnittstelle in einem DataModule und da kannst Du jede Änderung problemlos abfangen. GGf hast Du für unterschiedliche DBs und unterschiedliche Zugriffskomponenten auch unterschiedliche DataModules.
Deiner Hauptanwendung ist es vollkommen egal aus welcher DB die Daten kommen, da nur die eigentlichen Nutzdaten angefordert werden.
Einziges Problem ist dann allerdings, daß die allseits so beliebten DBGrid..DBEdit..DBIrgendwas nicht zum Einsatz kommen können, was wenn ich mir die entsprechenden Hilferufe anschaue bestimmt kein Manko ist.

Zitat:

Zitat von mkinzler (Beitrag 1223827)

Dann beschränkt man sich aber auf den gemeinsamsten Nenner. Das ist ja wie mit einem Porsche höchstens 80 Fahren :stupid:

ein Cheyenne mit 140 ist doch auch schon ganz schön, vor allem immer und überall und nicht nur auf der A3 bei Köln

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1223827)

Dann beschränkt man sich aber auf den gemeinsamsten Nenner. Das ist ja wie mit einem Porsche höchstens 80 Fahren :stupid:

Kommt auf den Aufwand und Mächtigkeit des DB-Abstraktionlayers an. So 200 dürfte dann schon erreichbar sein was für viele Anwendungsfälle genügt.
Oft ist es nicht der DB-Layer der bremst sondern ungeschickte Implementierung wie alle 2 Mio. Datensätze holen um auf Clientseite 3 davon zu benötigen.

[mkinzler]

Meine Antwort bezog sich auf

Zitat:

Man sollte nur tunlichst vermeiden einen spezifischen SQL Dialekt eines DBMS zu benutzen, und entweder sich ganz auf die Abstraktionen durch die Komponenten stützen, oder ganz simple Standard-Queries.

und nicht auf die Implementierung einer Abstraktionsschicht, den diese verwendet dann wohl DBMS abhängigen Code!

[Medium]

Nichts kommt ohne Preis daher ;)
Natürlich hängt da dann viel von der Abstraktionsschicht ab, und ob die ggf. intern je nach DBMS optimierte Queries benutzt oder nicht. Wichtig war mir nur der Punkt, dass man im eigentlichen Business-Code nicht mehr mit SQL-Strings rum hantiert. Wo, wie, womit und wie gut das bewerkstelligt wird steht auf einem anderen Blatt. Und wenn man ganz "fancy" wird, vielleicht sogar ein ORM (um's mal in die Runde zu werfen).

Man kann solche Dinge auch beliebig weit treiben, ohne Probleme bis in die Sinnlosigkeit. Da muss man dann abwägen, wie viel man für seine Anwendung an Entkopplung vom DBMS, an Geschwindigkeit, an einfacher Benutzung etc. wirklich braucht. Trivial ist das, schon bei mittlgroßen Projekten, sicherlich nicht.
Wenn die Arbeit zum Erreichen des Wunschziels die für den ggf. ansonsten entstehenden Pflegeaufwand übersteigt, hat man es vermutlich zu gut gemeint. Das betrifft alles aber auch wirklich nur die Programm-Seite, sprich "komme ich an meine DB heran?" wenn ich das DBMS und/oder die Komponenten austauschen muss. Die Daten sind dadurch noch lange nicht sicher. BACKUPS!!

[Furtbichler]

Es gibt eine SQL-Komponente, die mit Text-Dateien arbeitet: TjanSQL. Download? klick!

Taugt für einige tausend Datensätze. Einfach mal probieren.

das Textformat wird wohl das sein, was Du suchst..

[Perlsau]

Zitat:

Zitat von BBoy (Beitrag 1223807)

ok, also kann ich das vergessen endlich eine datendatei zu haben die ich jederzeit nutzen kann auch wenn es die Komponente wie z.B. Absolute Database nicht mehr gibt ?

Absolute Database ist keine Komponente. Komponenten sind das, was du auf deiner Komponentenpalette zur Verfügung hast. Bei Absolute Database dagegen handelt es sich um ein RDBMS (Relational Database Management System). Das, wo du deine Daten hineinschreibst, ist die Datenbank, und auch die ist keine Komponente.

Zitat:

Zitat von BBoy (Beitrag 1223807)

Kennt wer eine sql embedded database die kostenlos ist und wovon man ausgehen kann das es die lange gibt?

An dieser Stelle empfehle ich immer gerne Firebird Embedded. Zur Entwicklung einer entsprechenden Anwendung installiert man sich erst einmal einen Firebird-Server, denn damit läßt sich einfacher entwickeln als mit der Embedded-Variante. Danach lädt man sich die Zeos-Komponenten herunter und installiert diese in seiner Delphi-IDE. Wenn die Anwendung fertig ist, kopiert man die Embedded-Dateien ins BIN-Verzeichnis des Projekts und stellt die Connect-Parameter entsprechend um. Seit Firebird 2.5 muß die Datenbank der Embedded-Variante nicht mehr im Anwendungs-Ordner liegen und kann sogar von mehreren Benutzern gleichzeitig verwendet werden (embedded heißt "eingebettet" und bedeutet, daß zum Betrieb kein Firebird-Server installiert sein muß, denn die Server-Funktionalität wird von einer entsprechend modifizierten fbclient.dll bereitgestellt).

Ansonsten schließe ich mich dem hier vielfach gegebenen Ratschlag an, vor dem Schreiben einer Datenbank-Anwendung doch bitte die Datenbank-Grundlagen zu erlernen.

[BUG]

Zitat:

Zitat von Furtbichler (Beitrag 1223914)

das Textformat wird wohl das sein, was Du suchst..

Das Format vielleicht ... aber eine uralte Komponente, dessen Homepage im Netz nicht zu finden ist und die man nur noch über Filesharing-Seiten bekommt :?

Da sollte SQLite doch um einiges zukunftssicherer sein, schon weil es praktisch überall* genutzt wird und Public Domain ist.
* Einfach mal auf deinem Rechner nach sqlite*.dll suchen. Wenn du einige Programme installiert hast, bestehen gute Chancen.

[Furtbichler]

Zitat:

Zitat von BUG (Beitrag 1223954)

aber eine uralte Komponente, dessen Homepage im Netz nicht zu finden ist und die man nur noch über Filesharing-Seiten bekommt :?

Da der Quellcode vorhanden ist, und das Ganze auch nicht sonderlich komplex ist, sehe ich da kein Problem, du etwa?

Zitat:

Zitat von BBoy (Beitrag 1223794)

... die das dann wieder in einem speziellen Format speichern (*.abs)? Also das eine reine .sql Datei die ich auch in vielen Jahrzehnten noch nutzen kann?

Der TE hatte bestimmte Anforderungen, die mit dieser Komponente erschlagen worden wären. Bei SQLite wäre ich mir nicht sicher, ob man die "in vielen Jahrzehnten noch nutzen kann". Bei Text-Dateien bin ich mir sehr sicher.

Ich sage ja nicht, das die von mir vorgeschlagene Lösung das Gelbe vom Ei ist, und deshalb schrieb ich auch, das man es mal ausprobieren sollte. Aber davor schien die Ansicht vorzuherschen, das es soetwas nicht gibt, und das stimmt nicht.

Wenn ich eine solche Anforderung auf den Tisch bekäme (Datenbank mit lesbarem Format), bearbeitbar mit SQL, würde ich diese Komponente zumindest anschauen. Ist der Quellcode gut dokumentiert, würde ich sie einfach übernehmen.