SQL only Dantenbank erstellen ?

[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....
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 von Sir Rufo:

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

[Sir Rufo]

Zitat von 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....
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 von 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....
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 von mkinzler:

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

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 von mkinzler:

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

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!