Welcher Zeichensatz für neue DB (über Zeos) empfehlenswert?

[MatthiasR]

Zitat von Alfredo:

Der Professor meine Bruders hat einmal folgendes gesagt:

Zitat:

Erfahrung ist die Summe der gemachten Fehler, möglichst nicht der eigenen.

In diesem Sinne wollte ich meine Anmerkungen verstanden wissen.

Ich kann deine Bedenken gegenüber Postgres ja verstehen, nur denke ich, dass sie sich größtenteils 1-zu-1 auch auf andere DBMS übertragen lassen und nicht wirklich Postgres-spezifisch sind. Sprich: die gleichen Probleme habe ich auch bei anderen System in gleicher oder ähnlicher Form. Oder ich habe eben andere Probleme, die ich bspw. mit Postgres nicht hätte. DAS optimale System, das alle Bedürfnisse eines jeden Users zu 100% befriedigt, gibt es nunmal nicht. Postgres macht auf mich bisher jedoch einen sehr ausgegorenen Eindruck und ich bin noch auf kein Problem gestoßen, das sich nicht lösen ließe. Trotzdem bin ich dir für deine Anregungen dankbar!

Zitat von Alfredo:

Zitat:

Was ist an pg_dump mit hohem Aufwand verbunden, wenn man erstmal die passenden Parameter für sich gefunden hat?

http://www.pro-linux.de/berichte/postgresql-daten-sichern.html

Auch in deinem Link kann ich nicht erkennen, was an pg_dump so ein großer Aufwand sein soll. Gut, es ist eine von vielen Möglichkeiten, eine Datensicherung zu betreiben. Eine Point-in-Time-Recovery ist sicherlich mit etwas mehr Aufwand verbunden, damit habe ich mich auch schonmal beschäftigt. Ist aber in der Form unter anderen DBMS sicherlich auch nicht anders, oder?

[QuickAndDirty]

@Infect:
Es macht sinn den Datenbankzugriff in einer Klasse oder mehreren zu Kapseln, die sich beim wechsel zu einer anderen Datenbank
leicht mit neuen SQLs füllen lassen.
Das Problem ist das verschiedene SQL Server verschiedene SQL-Sytnaxen haben (man nehme nur mal das TimeStamp Format nach 2003 Standard).
Du kapselst nicht nach Insert, Update, Delete...sondern nach Service Kriterien.
Eine Funktional in sich geschlossene Aufgabe.

Delphi-Quellcode:

Function TKunde_Persistent.Anlegen(Name, Vorname, Adresse, Kategorie:String):boolean;
Function TKunde_Persistent.Suchen(FilterName, FilterVorname, FilterAdresse, FilterKategorie:String; aKunde : TKunde_View):boolean

Sowas in der Art.

Der Vorteil ist das du all die Probleme die wir zum Beispiel gerade haben (Datenbankumstellung läuft seit 3 Jahren) vermeidest.

Es schadet natürlich nicht, noch eine Bridge Pattern ebene und eine Facade Pattern Ebene dahinter aufzuziehen, um jeder zeit auch
von Zeos los kommen zu können.

[MatthiasR]

@QuickAndDirty: Ich kann mir ehrlich gesagt schwer vorstellen, dass eine so aufgebaute Schnittstelle zwischen Anwendung und Datenbank wirklich so das gelbe vom Ei ist. Klar wäre man dann Anwendungsseitig völlig losgelöst von der Datenquelle darunter. Theoretisch könnten die Daten dann z.B. sogar in XML-Dateien liegen, die in der "Suchen"-Funktion nur ausgeparsed werden. An sich ne feine Sache.

Aber ist das nicht mit erheblichem Anpassungsauswand verbunden, wenn man z.B. in Zukunft noch nach allen möglichen anderen Kriterien nach Kunden suchen möchte, als nur Vor-/Nachname oder Adresse? Du müsstest dann entweder deine Schnittstelle immer anpassen - sprich Parameter-Leiste erweitern - und damit auch alle aufrufenden Methoden, oder deine bestehende Suchen-Funktion ständig überschreiben. Dadurch würde das mit der Zeit immer unübersichtlicher werden. Dann hättest du irgendwann 5 verschiedene Suchfunktionen, die alle eigentlich dasselbe machen, nur jede ein bisschen anders. Genauso, wenn du die Ergebnisse nach allen möglichen Kriterien auf- oder absteigend sortiert haben möchtest. Wie kriegt man sowas in den Griff?

[QuickAndDirty]

Eigentlich dachte ich daran ALLE Attribute des Kunden zu verwenden...nur hatte ich nicht so viel Zeit mir welche auszudenken...neben der Arbeit...Die Methoden müssen eben alle Parameter die du dir wünscht enthalten...

Und Gerade die Teilung in Persistenz(Modell) und GUI(View) Objekte macht Anpassungen leicht...
Und das Änderungen an der Datenbankstruktur irgendwie immer Aufwand nach sich ziehen (Setup, Update, Persistenz, GUI) ist
bei Relationalen Datenbanken sowie so immer gegeben...

(Wirklich unproblematisch sind Änderungen am Datenmodell dann nur wenn man a la J2EE Obejct relationale Persistenz Funktionen implementiert...auf Kosten der Geschwindigkeit!)

Du musst das ja so nicht machen, aber ich habe nur schlechte Erfahrungen mit Gui-Datenobjekten die überall in *.dfm 's und Code Verteilten Daten-Zusammenhänge. Es ist nicht so leicht das alles umzuarbeiten, die TTales und TQuerys liegen alle auf Formularen...
Mal wird hier ein Insert gemacht mal dort ein anderer.... wenigstens unsere filterkomponente funktioniert Zentral...
700K Code Zeilen und Hunderte BDE-Objekte und teilweise mehrfach verschiedenen Vorgehensweisen je nach Datenbank(Paradox,Orakel,MSSQL, DBISAM(ohne BDE)...

Jetzt wird es Stück für Stück eben Richtig gemacht und die Datenbankzugriffe auf eine Facade umgeleitet, wenn das durch ist, werden GUI und Persistenz getrennt, die Logik ist bereits weitest gehend gekapselt damit die WEB Lösung der Anwendung möglich ist.

[MatthiasR]

Wie gesagt, die Hintergründe für deinen Ansatz leuchten mir schon ein. Aber schränkt ihr euch selbst damit nicht unheimlich ein? Da hat man ein so mächtiges Werkzeug wie SQL, kann es aber nicht richtig nutzen, weil die Schnittstelle nach außen kein SQL mehr unterstützt, sondern nur noch diese ziemlich kastrierte "Suchen"-Funktion z.B. Oder wie würdest du das realisieren, wenn ich jetzt innerhalb der Kundentabelle z.B. alle männlichen Kunden suchen will, deren Geburtsdatum zwischen 1960 und 1970 liegt, und alle weiblichen, deren Geburtsdatum zwischen 1970 und 1980 liegt? Wobei das ja noch eine ziemlich lächerliche Abfrage wäre, in der Praxis schaut das ja meist noch viel viel haariger aus. Das kannst du doch gar nicht so weit abstrahieren, um alle denkbaren und auch sinnvollen Möglichkeiten abzudecken . Oder schlägst du tatsächlich vor, für jede Abfrage eine eigene Funktion zu implementieren???

EDIT: Und was ist, wenn irgendwann, wenn die Schnittstelle mal fertig ist und überall so eingebaut wurde, neue Suchkriterien hinzukommen, weil einfach die Anforderung dazu besteht? Wird dann jeweils eine neue Such-Funktion geschrieben, die eben die neuen Kriterien abdeckt oder wird gar die bestehende Suchfunktion angepasst und damit die ZIG Stellen, an denen sie mit den "alten" Parametern aufgerufen wurde? Ersterer Fall würde einen unheimlichen Wildwuchs an Funktionen erzeugen, die alle irgendwie dasselbe machen, in dem man irgendwann die Übersicht verliert. Letzterer Fall würde bewirken, dass sich die Schnittstelle ständig ändern würde und damit alle aufrufenden Funktionen gleich mit. Beides möchte ICH zumindest nicht verantworten müssen...

[QuickAndDirty]

Bei uns sind immer alle Eigenschaften suchbar.
Es gibt alle Eigenschaften 3 mal in dem SuchObjekt
Einmal als VON einmal als BIS und einmal als GLEICH Eigenschaften.
zusätzlich ist für Poweruser ein direkter SQL_zugriff Möglich.
der zuletzt angewendete Filter wird für die User gespeichert und
beim erneuten anschauen der Maske automatisch ausgeführt.

Die Such Maske sieht auch Identisch aus wie die jeweilige Stammdatenmaske,
nur das es sie eben auf 3 Tabsheets (VON,BIS,GLEICH) gibt.

Und die Eine Funktion überall zu finden ist kein Probelm. Nur wird sie
ja nicht überall benutzt. Sondern im Kontext eines Services umgesetzt.

Wenn du natürlich eine Freie-Daten-Recherche ermöglichen willst ist der vorhin aufgezeigte weg nicht sehr optimal...
Eine frei Datenrecherche bräuchte einen direkten SQL Zugriff oder in einem Decisioncube aufbereitete Daten...UND Poweruser die Ahnung haben.

Allerdings haben wir kaum derartige Power User in unserem Kundenkreis, und für Sonderwünsche außerhalb des Standard Produkts existieren Anpassbare Oberflächen und ein Makrointerpreter(c-Interpreter).

Grundsätzlich ist eine MVC Trennung und eine SOA Orientierung für Anwendungssoftware aus meiner Sicht recht erstrebenswert um die Wartbarkeit zu erhöhen.
Der vorhin aufgezeigte Weg ist dabei ein Kompromiss zwischen einfacher Veränderbarkeit (Objektrelationales-Persistenz-Framework) und hoher Performance(Große Teile der Programmlogik in Stored-Procedures), der die Datenbank und Oberflächen-Unabhängigkeit der Geschäftslogik gewährleistet.

[Bernhard Geyer]

Mann kann die DB-Neutrale Schnittstelle soweit aufbohren das auch SQL-Joins oder TOP/LIMIT in generischer Art unterstützt wird bzw. Aggregatfunktionen. Ist halt Aufwändiger.

[MatthiasR]

Zitat von Bernhard Geyer:

Mann kann die DB-Neutrale Schnittstelle soweit aufbohren das auch SQL-Joins oder TOP/LIMIT in generischer Art unterstützt wird bzw. Aggregatfunktionen. Ist halt Aufwändiger.

Redest du jetzt eigentlich auch von einer Schnittstelle im Stile der von QuickAndDirty oder von einer in der Art, wie ich sie mir vorgestellt hatte, mit Klassen oder Funktionen, die einem lediglich das Datenbank-"Slang"-abhängige Zusammenbasteln der SQL-Statements abnehmen? Also sowas in der Art (zur Erinnerung):
function Select(const Select, From, Where: string): ResultSet; Um auch das ResultSet plattformneutral zu halten, sprich, die Zeos-Query nach außen hin zu "verdecken", würde sich da ein TClientDataset für anbieten? Also die Datenmenge einer Query in ein ClientDataset laden und das dann als Ergebnis zurück zu geben?