ZeosLib -- wozu überhaupt?

[Bernhard Geyer]

Zitat:

Zitat von gsh

Aber im großen und ganzen glaub ich schon dran das dies bei standart SQL Befehlen ohne Probleme funktionieren sollte.

Solange du keine Beschränkten Datenmengen (LIMIT/TOP), keine speziellen Datentypen, keine DDL (CREATE TABLE ...) und und und verwendest geht das. Ansonsten mußt du dir auf jedenfall noch was drüber "stricken" (Stichwort: Bridge-Pattern).

[gsh]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von gsh

Aber im großen und ganzen glaub ich schon dran das dies bei standart SQL Befehlen ohne Probleme funktionieren sollte.

Solange du keine Beschränkten Datenmengen (LIMIT/TOP), keine speziellen Datentypen, keine DDL (CREATE TABLE ...) und und und verwendest geht das. Ansonsten mußt du dir auf jedenfall noch was drüber "stricken" (Stichwort: Bridge-Pattern).

Also bei mir ist es so das ich den Server eigentlich für MySQL auslege (Mit dieser teste ich). Wenn jetzt ein kunde eine andere Datenbank einsetzt und bei irgendwas probleme hat weil die andere Datenbank den SQL Befehl nicht verträgt, dann werde ich meistens eine alternativ SQL Abfrage für die eine Datenbank einbauen.

Aber bis jetzt bin ich noch auf keine Probleme mit meinen Befehlen gestossen.

[Hansa]

Zitat:

Zitat von gsh

Also bei mir ist es so das ich den Server eigentlich für MySQL auslege (Mit dieser teste ich). Wenn jetzt ein kunde eine andere Datenbank einsetzt und bei irgendwas probleme hat weil die andere Datenbank den SQL Befehl nicht verträgt, dann werde ich meistens eine alternativ SQL Abfrage für die eine Datenbank einbauen.

Du denkst anscheinend, mehrere Datenbanken zu "unterstützen", das sei ein Vorteil ? Wie bei Delphi oder was ? Das kann aber schnell auch zum gravierendem Nachteil ausarten. :shock: Du musst eventuell einen gewaltigen Aufwand betreiben um das eigene Programm kompatibel zu halten. Wer soll denn das bezahlen ? Einarbeitung in diverse DB-Versionen etc. Gar nicht zu denken an Optimierung. An ein "Ausreizen" eines gewissen DBMS ist IMHO kaum zu denken. Der einzige Spezialfall, den ich gelten lasse, sind bestehende Datenbestände (mit Fremdprogramm erstellte) und Du sollst ein Zusatzprogramm dafür schreiben.

Eine DB ist auch kein Auto. Da hat man wohl einen Vorteil, sagen zu können : "Solls ein VW sein, ein Opel, ein Mercedes oder was ganz billiges ?". Fast kein Endanwender weiß aber überhaupt was eine Datenbank ist. Alternativen anzubieten sorgt eher für Verunsicherung. Wenn der "PC-Experte aus der Nachbarschaft" dann noch dazu kommt, dann ist das Geschäft eventuell schon versaut. Wenn einem Endanwender schon ganz klar wäre, was er als DB braucht, dann frage ich mich, warum die Frage "Welche Datenbank" in allen Varianten so oft sogar hier in der DP auftaucht.

[Sir Rufo]

Lieber Hansa, dein Vergleich hinkt ein wenig ... denn der Kunde hat z.B. vielleicht schon ein Datenbanksystem.

Zitat:

Zitat von gsh

Wenn jetzt ein kunde eine andere Datenbank einsetzt und bei irgendwas probleme hat weil die andere Datenbank den SQL Befehl nicht verträgt, dann werde ich meistens eine alternativ SQL Abfrage für die eine Datenbank einbauen.

Was nun?

a) Geschäft nicht machen?
b) Kunde eine neue zusätzliche DB aufreden?

Was viele nicht bedenken, ist das es mit einem DB-System (als Stück Software) alleine doch nicht getan ist.

a) Hardware (Festplatten, RAM, CPU)
b) Sicherung (DB-Treiber für das Backup-System)
c) Monitoring
d) Manpower (für die Wartung)

oder kaufst du dir ein zusätzliches Auto, weil das Autoradio xy nur in einem bestimmten Automodell funktioniert, oder steigst auf dieses Auto komplett um? Vor allem passt das neue Auto gar nicht in die Garage und die Auffahrt kommt es auch nicht mehr rauf.

Zitat:

Zitat von gsh

Aber bis jetzt bin ich noch auf keine Probleme mit meinen Befehlen gestossen.

Und es scheint bislang auch noch ohne viel Pflegeaufwand zu funktionieren, warum also nicht. Zumal man dem Kunden diese Dienstleistung der Anpassung auch immer noch in Rechnung stellen kann.

Sollte weder eine Anpassung der Anwendung (ist dem Kunden zu teuer) oder ein zusätzliches DB-System (Pflege dem Kunden zu aufwändig) in Frage kommen, dann ist das nicht die richtige Anwendung für den Kunden.

Ich fahre auch sehr gerne Aston Martin und die verkaufen mir liebend gerne einen Wagen, aber der passt nicht in meine Garage :mrgreen: also gibt es keinen.

cu

Oliver

[gsh]

Auch wenn ich hier ganz OT schreibe aber eins muss ich noch klar stellen:
Ich supporte nur MYSQL in der neuesten Version. Wenn der Kunde das Problem mit einer anderen DB meldet und es ein geringer Aufwand es zu beheben (z.b. eine eigene SQL Abfrage für diese DB) dann werde ich es machen. Aber ich werde nie garantieren das die neueste version immer mit jeder DB arbeitet.

Beim rest stimme ich Sir Rufo zu. :zwinker:

[Bernhard Geyer]

Noch ein Nachteil wenn man den Kunden sein DB-System aufdrängt: Man ist als Lieferant dafür verantwortlich das auch solche "Nebensächlichkeiten" wie Backups, Datensicherheit, ... von einem Bereitgestellt werden. So kann man einfach eine weitere DB in eine bestehende Installation einrichten und gut ist. Backup, ... sind alle schon am laufen (sollte jedenfalls, oder der Admin hat einen wackligen Job). Oder willst DU (Hansa) dafür verantwortlich sein das das Firmennetz ausfällt weil niemand wusste das auf Rechner xy die DB MS SQL Server/MySQL/Oracle... ungepatcht mit Offenen Scheunentoren lief?

[TBx]

@Bernhard Geyer: Das ist nun doch ein wenig überspitzt. Nur weil ich beim Kunden ein bestimmtes Datenbanksystem voraussetze, bin ich noch lange nicht für selbiges verantwortlich.
Ist das DB-System bein Kunden bereits im Einsatz, ist alles ok, wenn nicht, kläre ich mit dem Kunden, wer die Einrichtung und Wartung übernimmt. Paßt es in den Auftrag und bei mir zeitlich, biete ich es mit an. Ggf. spreche ich auch Empfehlungen für andere FIrmen/Dienstleister aus, dies zu tun. Es kommt auch vor, dass ein MA des Kunden dann für die Wartung der DB ausgebildet wird (ggf. von mir).
Sträflich wäre es eigentlich nur, den Kunden nicht über die Risiken und die Aufgaben des DB-Admins zu informieren. Und das tue ich sowohl dann, wenn mir ein DB-System zur Verfügung gestellt wird als auch, wenn das System für mich/durch mich aufgesetzt wird. Dann liegt die Verantwortung beim Kunden.
Ich denke, hier kann ich sogar für den Kunden wesentlich mehr Effizienz und Sicherheit bieten, da ich das von mir verwendete DB-System eben auch am Besten kenne.

My 2 Cent

Thomas

[Bernhard Geyer]

Zitat:

Zitat von TBx

@Bernhard Geyer: Das ist nun doch ein wenig überspitzt.

Mag es. Wir haben aber schon Kunden die versuchen jedliche Problem auf einen abzuladen: "Sie haben da was installiert und jetzt geht xyz nicht mehr.". Schlecht ist wenn man nun sowas wie eine DB installiert die alles mögliche mitinstalliert. Da bist du nun erstmal in der Pflicht zu beweisen das es deine Installation nicht schuldig ist. Gut ist wenn man z.B. ein Delphi-App mit XCopy-Fähigkeit hat und damit defintiv nichts am System verändert :-)

[Hansa]

Zitat:

Zitat von Bernhard Geyer

..Wir haben aber schon Kunden die versuchen jedliche Problem auf einen abzuladen: "Sie haben da was installiert und jetzt geht xyz nicht mehr."...

Ist bekannt (sehr schlimmes schwarzer Peter Prinzip im Zusammenhang mit DAUs :shock: ). Nur : Die DB wird so oder so installiert/kopiert. Was soll es da, zusätzlich dem DAU noch eine ihn völlig überfordernde Auswahl zu lassen : "wählen sie die DB : Interbase 6.5, MySql, MS-SQL, Firebird, postgre, Oracle, Advantage, andere". Wie gesagt, man beachte hier auch die Frage "Welche Datenbank ?" sogar in der DP. Hat jemand KlickTel, Musicmatch oder sonstwas im Einsatz ? Falls ja : welche DB wird dafür verwendet ? Wurde die installiert und wenn ja wohin ? Wer achtet bei MS Office darauf, Access nicht zu installieren ? Bei letzterem wird sogar gerne darauf verwiesen, dass das sowieso auf jedem Rechner ist. 8)