Hi
Für ein
DB-Projekt benötigen wir berechnete Datenbankfelder. Eigentlich wollen wir sogar mehr als das: Nämlich Getter und Setter-Methoden für einzelne Datenbankfelder.
Nun ist das mit MS-
SQL (und mit vielen anderen
DBMS) kein Problem: Über Updateable Views, Trigger etc. bekommt man das hin. Nur ist man dann in den Getter und Setter-Methoden auf T-
SQL beschränkt.
Weiterhin wollen wir keine horrenden Summen für MSSQL2005+ ausgeben, bei der man Stored Procedures in C# schreiben kann.
Ein bisheriger Ansatz implementiert eine Metadatenbank auf dem
DBMS und wickelt die gesamte Datenaquirierung in einer Mittelschicht ab. Das bedeutet jedoch sowohl einen massiven Performanceverlust, als auch eine starke Einschränkung der Zugriffsmöglichkeiten: Mit herkömmlichen
SQL ist ja nichts mehr zu holen, außer man implementiert einen kompletten
SQL-Interpreter.
Ich hatte die Idee, die Getter und Setter über 'extended Stored Procedures' zu implementieren. In der XSP läuft ein Script-Interpreter. Welcher, ist erstmal egal. Wichtig ist nur, das die Script-Engine widerum Zugriff auf die komplette
DB hat, und zwar auf Record-, Tabellen- und Datenbankebene. Problem bei diesem Ansatz wäre die Gefahr, das eine fehlerhaft implementierte XSP (Endlosschleife, Deadlock, unbehandelte
Exception) das gesammte
DBMS mit in den Abgrund reißen könnte. Der Vorteil könnte die Performance sein.
Was haltet ihr davon? Gibt es bessere Ansätze (hinsichtlich Performance und Stabilität)? Hat jemand Erfahrungen mit selbstgeschriebenen XSP? Gibt es andere (freie!)
DBMS, mit denen man soetwas hinkriegen könnte?
Ich möchte keine Lösung, die auf beliebigen
DBMS aufsetzt und o.g. Nachteile mitbringt, sondern eine verdammt schnelle, robuste und mächtige Lösung für ein freies
DBMS (wobei ich
MSSQL Express als 'frei' definiere, obwohl es das im gesellschaftsphilosophischen Sinne ja nicht ist).