Berechnete Felder auf DBMS-Ebene? Konzeptvorschläge gesucht

[alzaimar]

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