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

[MatthiasR]

Da wir momentan was PostgreSQL angeht noch recht grün hinter den Ohren sind, uns aber entschieden haben, es für kommende Projekte einzusetzen, stellt sich für mich gerade die Frage nach dem "richtigen" Zeichensatz für neue Datenbanken. Zugegriffen werden soll darauf mittels den Zeos-Komponenten (momentan) aus Delphi 7.

Standardmäßig ist bei PostgreSQL ja UTF8 als Zeichensatz für neue Datenbanken eingestellt (in diesem pgAdmin-Tool). Da UTF8 sowohl unter einem Windows- als auch Linux-Server zu Verfügung steht, wäre das erstmal die erste Wahl. Problem an der Geschichte ist nur die Client-Seite: Umlaute werden im Delphi-DBGrid falsch angezeigt. Auch wenn ich per INSERT-Befehl einen AnsiString, der Umlaute enthält, in eine UTF8-Datenbank einfügen will, kommt eine Fehlermeldung:

Zitat:

SQL Fehler: ERROR: invalid byte sequence for encoding "UTF8": 0xfc
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".

Eine Möglichkeit, den Fehler zu umgehen, wäre da vorherige Wandeln des AnsiString in UTF8 mittels AnsiToUTF8. Allerdings ist das recht mühsam, da jedes mal dran zu denken, außerdem löst das nach wie vor das Problem der Anzeige im DBGrid nicht.

Was also tun?

1. Gibt es irgend eine Möglichkeit, das DBGrid (oder DataSource oder Query oder Connection) irgendwie auf UTF8 umzustellen?

2. Ist UTF8 als Zeichensatz überhaupt empfehlenswert? Ich habe bei meinen bisherigen Tests auch den WIN1252-zeichensatz verwendet, weil ich damit die Probleme nicht habe. Allerdings steht der mir unter Linux nicht zu Verfügung, und wir haben auch Linux DB-Server im Einsatz.

Vielen Dank für eure Hilfe :) !

[MatthiasR]

OK, löse hier mal selbst auf: das Zauberwort heißt Client-Encoding. Ich übermittle dem Postgres-Server nun nach dem verbinden, dass ich als Client-Encoding LATIN9 (= ISO-8859-15) verwenden will, und prompt passen die Umlaute im DBGrid wieder :) . Und auch bei INSERT-Befehlen beschwert er sich nun nicht mehr über fehlerhafte UTF-8-zeichen, weil er die Daten fortan auch in LATIN9 erwartet.

Delphi-Quellcode:

procedure TForm1.ZConnection1AfterConnect(Sender: TObject);
begin
  ZConnection1.ExecuteDirect('SET CLIENT_ENCODING TO ''LATIN9'';');
end;

Für mich ein gangbarer Weg :-D

[Bernhard Geyer]

Kommt ZEOS nicht mit UTF8 zurecht so das es eine Transparente Codierung UTF8 <-> Unicode vornimmt :gruebel:

Für größere Apps würde ich eh die DB-Schnittstelle z.B. mit Bridge-Pattern kapseln und wenn möglich auf DB-Sensitive Controls verzichten. Damit kannst du die nötigen Wandlungsfunktionsaufrufe in einer Klasse/Unit kapseln/zentrieren.

[MatthiasR]

Zitat:

Zitat von Bernhard Geyer

Kommt ZEOS nicht mit UTF8 zurecht so das es eine Transparente Codierung UTF8 <-> Unicode vornimmt :gruebel:

Ich weiß nicht, ob ich dich richtig verstanden habe, aber ein "INSERT INTO tabelle VALUES ('türöffner');" mittels TZQuery auf eine UTF8-Datenbank endet in einem Fehler. Und das DBGrid in Delphi 7 ist ja noch nicht Unicode-fähig, falls du das gemeint hast.

Zitat:

Zitat von Bernhard Geyer

Für größere Apps würde ich eh die DB-Schnittstelle z.B. mit Bridge-Pattern kapseln und wenn möglich auf DB-Sensitive Controls verzichten. Damit kannst du die nötigen Wandlungsfunktionsaufrufe in einer Klasse/Unit kapseln/zentrieren.

Was spricht gegen datensensitive Controls wie ein DBGrid? Das Ergebnis einer komplexeren SQL-Abfrage möchte ich jedenfalls nicht von Hand in ein Grid eintragen müssen...
Eine gewisse Zentralisierung des Datenzugriffs ließe sich ja mittels Connection auf Datenmodul erreichen. Was spricht dagegen, bei den verschiedenen Formularen mit DB-Zugriff auf die TZQuery zurückzugreifen?

[Bernhard Geyer]

Zitat:

Zitat von Infect

Ich weiß nicht, ob ich dich richtig verstanden habe, aber ein "INSERT INTO tabelle VALUES ('türöffner');" mittels TZQuery auf eine UTF8-Datenbank endet in einem Fehler.

Man sollte eh immer parametrisierte Abfragen machen. Dann vermeitet man Problem die bei direkter angabe der Werte entstehen.

Zitat:

Zitat von Infect

Und das DBGrid in Delphi 7 ist ja noch nicht Unicode-fähig, falls du das gemeint hast.

Um ein üöä zu bekommen braucht man keine Unicodefähiges Grid.

Zitat:

Zitat von Bernhard Geyer

Was spricht gegen datensensitive Controls wie ein DBGrid? Das Ergebnis einer komplexeren SQL-Abfrage möchte ich jedenfalls nicht von Hand in ein Grid eintragen müssen...

Zig mal gemacht - Äh einmal gemacht. Ist für eine einfache lösung vieleicht 20 Zeilen lang.

Zitat:

Zitat von Bernhard Geyer

Eine gewisse Zentralisierung des Datenzugriffs ließe sich ja mittels Connection auf Datenmodul erreichen. Was spricht dagegen, bei den verschiedenen Formularen mit DB-Zugriff auf die TZQuery zurückzugreifen?

Vermeidung nur ein DBMS zu unterstützen zu können (falls deine App verkauft werden soll). Wenn man 2-3 Anbietet kann der Kunde seine eh schon im Haus befindliche DB verwenden. Bei einer bist immer DU als SW-Entwickler für alles Verantwortlich (bzw. es wird versucht dich dafür verantwortlich zu machen): "Sie haben doch mal die DB auf unseren Server installiert. Jetzt geht das auf einmal das nicht und wir denken ihre DB ist schuld".

[MatthiasR]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Infect

Ich weiß nicht, ob ich dich richtig verstanden habe, aber ein "INSERT INTO tabelle VALUES ('türöffner');" mittels TZQuery auf eine UTF8-Datenbank endet in einem Fehler.

Man sollte eh immer parametrisierte Abfragen machen. Dann vermeitet man Problem die bei direkter angabe der Werte entstehen.

Sollte doch nur ein Beispiel sein, ich arbeite mit Parametern.

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Infect

Und das DBGrid in Delphi 7 ist ja noch nicht Unicode-fähig, falls du das gemeint hast.

Um ein üöä zu bekommen braucht man keine Unicodefähiges Grid.

Auch das ist mir klar. Ich wollte wissen was du mit "Transparente Codierung UTF8 <-> Unicode" gemeint hast.

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Infect

Was spricht gegen datensensitive Controls wie ein DBGrid? Das Ergebnis einer komplexeren SQL-Abfrage möchte ich jedenfalls nicht von Hand in ein Grid eintragen müssen...

Zig mal gemacht - Äh einmal gemacht. Ist für eine einfache lösung vieleicht 20 Zeilen lang.

Mit datensensitiven Controls eben 0 mal gemacht. Was ist also besser?

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Infect

Eine gewisse Zentralisierung des Datenzugriffs ließe sich ja mittels Connection auf Datenmodul erreichen. Was spricht dagegen, bei den verschiedenen Formularen mit DB-Zugriff auf die TZQuery zurückzugreifen?

Vermeidung nur ein DBMS zu unterstützen zu können (falls deine App verkauft werden soll). Wenn man 2-3 Anbietet kann der Kunde seine eh schon im Haus befindliche DB verwenden. Bei einer bist immer DU als SW-Entwickler für alles Verantwortlich (bzw. es wird versucht dich dafür verantwortlich zu machen): "Sie haben doch mal die DB auf unseren Server installiert. Jetzt geht das auf einmal das nicht und wir denken ihre DB ist schuld".

Die Zeos-Connection unterstützt ca. 8 verschiedene Datenbanken, außerdem noch ADO. Ich sehe nicht, wieso ich mich damit auf einen Anbieter, in diesem Fall Postgres, kastrieren würde?!?

[Alfredo]

Zu Eurer Datenbankwahl einige Hinweise:

Ich war auch überzeugt, dass Progress "die" Datenbank ist.

Die Praxis hat mich jedoch eines besseren belehrt.

1) Ihr solltet euch mit dem Thema Datensicherung auseinandersetzen
- Ihr werdet feststellen, dass diese bei Progress mit einem hohen
Aufwand verbunden ist.

2) Auf welchem Betriebssystem läuft in Zukunft der Postgress-Server?

a) Ich habe es unter Fedora aufgegeben mit Postgress zu arbeiten
- beim Update müssen alter und neuer Sever parallel laufen

b) Postgress wird derzeit intensiv gepflegt, was ja zunächst sehr
positiv ist, aber es wird dadurch ein regelmäßiger Updateauf-
wand verursacht
- wenn dann auch noch das Betriebssystem laufend hochgezogen
wird, dann geht das einem selbst und auch dem Kunden ganz
schön auf die Nerven
- es genügt eine einzige Fehlentscheidung und man hat richtig
Stress(z.B. hochziehen des Betriebssystem, ohne vorher einen
Dump der DB gezogen zu haben)

3) Einfach die DB zu wechseln ist Theorie.
- Postgress hat eine andere Schreibsyntax wie Firebird.

4) Zeos ist nicht frei von Problemen
- lies einfach mal im ZEOS-Forum mit

5) Heute ein neues Projekt mit D7 aufzusetzen ist auch nicht unproblematisch
- siehe die UTF8-Geschichte


Gruß
Alfred

[Bernhard Geyer]

Zitat:

Zitat von Infect

Auch das ist mir klar. Ich wollte wissen was du mit "Transparente Codierung UTF8 <-> Unicode" gemeint hast.

Transparent heißt das du außerhalb der Zugriffskomponenten nicht bemerkst ob die DB UTF8 ist oder nicht (Außer das ohne UTF8 z.B. Kyrilisch und Arabisch nicht gemeinsam geht)

Zitat:

Zitat von Infect

Die Zeos-Connection unterstützt ca. 8 verschiedene Datenbanken, außerdem noch ADO. Ich sehe nicht, wieso ich mich damit auf einen Anbieter, in diesem Fall Postgres, kastrieren würde?!?

Es unterstützt es, aber wenn du den Aufbau von SQL-Anweisungen zu stark im Quellcode streust hast du hohen aufwand auf andere SQL-Syntax zu wechseln.

[MatthiasR]

Zitat:

Zitat von Alfredo

1) Ihr solltet euch mit dem Thema Datensicherung auseinandersetzen
- Ihr werdet feststellen, dass diese bei Progress mit einem hohen
Aufwand verbunden ist.

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

Zitat:

Zitat von Alfredo

2) Auf welchem Betriebssystem läuft in Zukunft der Postgress-Server?

a) Ich habe es unter Fedora aufgegeben mit Postgress zu arbeiten
- beim Update müssen alter und neuer Sever parallel laufen

b) Postgress wird derzeit intensiv gepflegt, was ja zunächst sehr
positiv ist, aber es wird dadurch ein regelmäßiger Updateauf-
wand verursacht
- wenn dann auch noch das Betriebssystem laufend hochgezogen
wird, dann geht das einem selbst und auch dem Kunden ganz
schön auf die Nerven
- es genügt eine einzige Fehlentscheidung und man hat richtig
Stress(z.B. hochziehen des Betriebssystem, ohne vorher einen
Dump der DB gezogen zu haben)

Sowohl unter Windows, als auch Linux. Da es bei unseren Kunden nicht darauf ankommt, dass ihre Anlage rund um die Uhr läuft, haben wir bei Updates sicher nicht so den Stress, dass wir zwei Datenbank-Server parallel betreiben müssen. Außerdem werden wir sicherlich nicht jedes Mini-Update umgehend einspielen, sondern eher nur Major-Versions, sofern sie sinnvolle Verbesserungen bieten, von denen wir auch profitieren.

Zitat:

Zitat von Alfredo

3) Einfach die DB zu wechseln ist Theorie.
- Postgress hat eine andere Schreibsyntax wie Firebird.

Was jetzt aber nicht wirklich ein Punkt gegen Postgres ist, sondern genauso gut einer gegen Firebird, bzw. eigentlich gegen so gut wie jedes DBMS, oder? Mir ist schon klar, dass ein DB-Wechsel nicht von heute auf morgen zu machen ist, aber von Postgres auf Firebird zu wechseln ist genauso schwierig, wie von Firebird auf mySQL oder was auch immer, möchte ich mal behaupten. Oder ist Postgres soooo viel spezieller als die anderen genannten Systeme?

Zitat:

Zitat von Alfredo

4) Zeos ist nicht frei von Problemen
- lies einfach mal im ZEOS-Forum mit

Welche Software ist das schon? Zeos ist zumindest open-source, was bei mir persönlich ein besseres Gefühl hinterlässt, als auf eine closed-source Variante zu setzen. Nicht zuletzt auch ein weiterer Grund für Postgres.

Zitat:

Zitat von Alfredo

5) Heute ein neues Projekt mit D7 aufzusetzen ist auch nicht unproblematisch
- siehe die UTF8-Geschichte

Soll ich nun deswegen den Compiler wechseln? Letztendlich lag es ja nur an einem nicht gesetzten Client-Encoding. Und genau dafür ist die Option ja da, damit man sie auch verwendet. Eine Codezeile hat das Problem bereits gelöst, also ist es ja im Nachhinein eigentlich nicht mal wirklich ein Problem gewesen.

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Infect

Auch das ist mir klar. Ich wollte wissen was du mit "Transparente Codierung UTF8 <-> Unicode" gemeint hast.

Transparent heißt das du außerhalb der Zugriffskomponenten nicht bemerkst ob die DB UTF8 ist oder nicht (Außer das ohne UTF8 z.B. Kyrilisch und Arabisch nicht gemeinsam geht)

Durch das Setzen des Client-Encodings auf LATIN9 als Options-property innerhalb der Zeos-Connection, bemerke ich doch ausserhalb der Zugriffs-Komponente überhaupt nicht, welcher Zeichensatz von der Datenbank physikalisch nun verwendet wird. Man legt den Client-Zeichensatz an EINER Stelle in der Client-Anwendung fest (da nur eine Connection verwendet wird) und der Fisch ist geputzt?!?

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Infect

Die Zeos-Connection unterstützt ca. 8 verschiedene Datenbanken, außerdem noch ADO. Ich sehe nicht, wieso ich mich damit auf einen Anbieter, in diesem Fall Postgres, kastrieren würde?!?

Es unterstützt es, aber wenn du den Aufbau von SQL-Anweisungen zu stark im Quellcode streust hast du hohen aufwand auf andere SQL-Syntax zu wechseln.

OK, das leuchtet mir ein. Du würdest also eine Schnittstellen-Unit vorschlagen, die z.B. Funktionen beinhaltet a la

Delphi-Quellcode:

function Select(const Select, From, Where: string): ResultSet;

Also dass die richtige und für das DBMS passende SQL-Syntax intern nur an einer Stelle zusammengestellt wird? Bei simplen SQL-Statements der Form "SELECT spalte FROM table WHERE column = value;" mag das ja noch gut machbar sein, aber wenn die Statements mal richtig komplex werden? Man kann ja nicht für jede Eventualität eine Schnittstellen-Funktion schreiben? Was würdest du da vorschlagen? Wie gesagt, den Sinn davon sehe ich ein.

[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.

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/pos...n-sichern.html

Gruß
Alfred

[MatthiasR]

Zitat:

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:

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 :gruebel: . 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:

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):

Delphi-Quellcode:

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?