![]() |
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
Zitat:
Zitat:
|
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
@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:
Sowas in der Art.
Function TKunde_Persistent.Anlegen(Name, Vorname, Adresse, Kategorie:String):boolean;
Function TKunde_Persistent.Suchen(FilterName, FilterVorname, FilterAdresse, FilterKategorie:String; aKunde : TKunde_View):boolean 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. |
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
@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? |
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
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. |
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
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... |
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
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. |
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
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.
|
Re: Welcher Zeichensatz für neue DB (über Zeos) empfehlenswe
Zitat:
Delphi-Quellcode:
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?
function Select(const Select, From, Where: string): ResultSet;
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz