Ihr solltet Euch von der klassischen 2-Schichten Architektur verabschieden, also Grid anzeigen und den User durchscrollen lassen. Bei 20 Anwendern geht es zwar gerade noch (wenn die Tabellen nicht zu lang sind), aber das ist eigentlich keine Art.
Der Anwender muss wissen, was er sehen will. Bei niedriger Bandbreite und schmalbrüstigen Mainframes baut man eine Suchmaske und zeigt den gefundenen Datensatz an. Heutzutage könnte man so 10-1000 Records saugen und die in einem Grid darstellen, z.B. eine Auftragsübersicht (machen wir gerade) o.ä. Wir haben das bei der Auftragsübersicht so gelöst, das beim Aufruf nur die heutigen Aufträge angezeigt werden. Ist gerade ein Kundensatz geladen, werden die heutigen Aufträge dieses Kunden angezeigt.
Über Filtereinstellungen kann man aber beliebige andere Queries ausführen. Wir deckeln die dann jedoch über ein 'SELECT TOP 1000...' o.ä. Wichtig ist außerdem, das man einen maximalen Timout einstellt, sodaß der
Anwender durch Auswahl von blödsinnigen Filterkriterien das System nicht zum Stehen bringt ("select * from Universe")
---
Ich finde es absolut zweit- wenn nicht gar drittrangig, ob man stored procedures nimmt, oder seine
SQL-Befehle im Klartext im Programm konstruiert, oder nicht. Das hängt IMMER vom Einsatzgebiet ab und hat
imho nix mit Multi-Tier zu tun.
Beispiel gegen Stored Procedures: Die Anwendung wird eventuell auf eine andere
DB portiert. Oder
MYSQL < 5.0, FlashFiler etc.
Beispiel für
SQL-Befehle im Klartext: Die Anwendung basiert auf Metadaten. Die Objekte/Entities sind also gar nicht 1:1 in der
DB abgebildet.
Aber, wenn ich mich auf eine
DB eingeschossen habe (ich verwende
MSSQL), dann habe ich mit Stored Procedures die besten Erfahrungen gemacht. Ich verwende die Mittelschicht nur, um die Verbindungen zur
DB zu bündeln, und um eventuell einen Cache für bestimmte Daten einzurichten.
Die Geschäftslogik wird weitestgehend in den Stored Procedures abgebildet. Warum? Weil man es so auch im laufenden Betrieb ändern kann, ohne die Mittelschicht runterzufahren. Allen Unkenrufen zum Trotz habe ich damit bisher null Probleme gehabt. Selbst komplizierteste Geschäftsregeln lassen sich über geschickte
SQL-Befehle oft verblüffend einfach realisieren. Wenn man ohne CURSOR arbeitet (was man fast immer kann), hat man absolut robuste und verdammich schnelle Lösungen, die mit klassischen Mitteln in der Mittelschicht ein vielfaches (Faktor 1000) an Zeit kosten.
Das ich ALLES über Stored Procedures und Updateable Views abbilde, hat aber nix mit dem Multitier zu tun, sondern mit meiner Prämisse, Aufgaben an Spezialisten zu deligieren. Und der
DB-Server ist DER Spezialist für Daten.
Grundsätzlich würde ich nicht mit
MYSQL arbeiten. Die
DB ist alles andere als umsonst (wenn ihr kommerziell damit arbeitet) und wird erst langsam ein richtiges
DBMS. Firebird oder eben
MSSQL (in der Express-Version absolut umsonst), PostGreSQL etc. sind weitaus bessere Vertreter einer
DB, stabil, ausgereift.
Was ich bei
MYSQL so grauenvoll finde ist, das man bei einem Servercrash doch Angst um die Daten haben muss (Stromausfall bei einem INSERT). Das passiert garantiert NIE bei
MSSQL (außer, die Platte ist hinüber).
Alter Schwede, kann man darüber viel schreiben.