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

[mkinzler]

Auf was kommt es dir an? das die SPs in einer Hochsprache entwickelt werden können? Oder nur auf die Performance?

[Bernhard Geyer]

Was meinst du mit Getter/Setter? Das du ein Objekt hast das einer Tabelle/Entität entspricht und dann per Setter/Getter-Methode jedes einzelne Feld mittels SQL-Update-Statment veränderst und nicht alle Felder in einem rutsch. Da kann ich mir dann vorstellen das du Performanceprobleme bekommst.

[mkinzler]

Ich glaube es bezieht sich auf die berechneten Felder. Er möchte diese updatebar machen. Obwohl ich mir das auch nicht ganz vorstellen kann, wie das gehen soll.
Z.B. Berechnetes Feld Alter: Soll dann Geburtsjahr bei Veränderung Alter geändert werden?

[Elvis]

Zitat von alzaimar:

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 bin mir nicht so sicher warum du im Client überhaupt noch mit SQL auf die Daten zugreifen willst. Was bringt dir das denn? Klingt für mich wie jemand, der nur öffentliche Felder in seinen Klassen hat und das dann OO nennt. (Um den Bogen mal etwas zu überspannen. )
Und vor allem: Wenn die DB auch außerhalb des Serverraums sichtbar ist: Wie zum Geier willst du sicherstellen, dass über deine XSProcs geändert wird?
Nehmen wir mal an, du hättest eine Lösung, die da Sinn macht[1]:
Ein freies DBMS mit exzellentem XSProc support wäre Firebird. Mit deinem Hintergrund wäre dann die Kombination Firebird/FreePascal interessant.
Es gibt aber auch andere DBMS, die nicht frei sind, aber die XPlattform sind und man durch die gesparten M$-Lizenzen schon wieder ziemlich gut dasteht.
Gerade als ein MSSQL-benutzer würde ich dir anraten mal eine Probefahrt mit Sybase SQL Anywhere zu machen.
Vorteil bei Firebird wäre seine abartig-einfache Handhabung. Nachteil bei Firebird wäre die Tatsache, dass du ihn lieber nicht mit zu komplexen SQLs scheuchst. Er braucht dann signifikant länger für den Ablaufplan und der wird dann auch nicht zu prickelnd werden...

Zitat:

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

MSSQL läuft nur auf Windows. Was IMHO eine bestenfalls lächerliche Plattform für eine DB ist. (CALs und andere unnütze Lizenzkosten sogar ignoriert)


[1] was für mich sinnlos erscheint muss es nicht für dich, da ich ja einfach nicht deine Umgebung/Anforderungen kenne

[alzaimar]

Hi Alle miteinander!

So ein Echo? Wahnsinn. Na denn

Zitat von mkinzler:

Auf was kommt es dir an? das die SPs in einer Hochsprache entwickelt werden können? Oder nur auf die Performance?

Performance und Flexibilität, nur darum geht es. Wenn der klassische (DB+AppServer) Weg wirklich der Beste ist, dann isses eben so.

Zitat von Bernhard Geyer:

Was meinst du mit Getter/Setter? Das du ein Objekt hast das einer Tabelle/Entität entspricht und dann per Setter/Getter-Methode jedes einzelne Feld mittels SQL-Update-Statment veränderst und nicht alle Felder in einem rutsch. Da kann ich mir dann vorstellen das du Performanceprobleme bekommst.

Natürlich nicht, aber wenn ich ein 'UPDATE Tabelle SET Feld1=xy, Feld2=yz...' ausführe, oder ein INSERT oder was weiss ich, dann soll eben ein 'Trigger' (das ist ja nichts anderes als eine Setter-Methode) in einer Hochsprache ausgeführt werden.

Zitat von mkinzler:

...Obwohl ich mir das auch nicht ganz vorstellen kann, wie das gehen soll...

Es sollen Constraints, Abhängigkeiten etc. implementiert werden. WIch sagte bereits, das man das alles über Trigger, updateable views etc. abbilden kann. Das ist mir aber zu unübersichtlich.

Zitat von Elvis:

Ich bin mir nicht so sicher warum du im Client überhaupt noch mit SQL auf die Daten zugreifen willst.

Der 'Client' kann auch eine Mittelschicht, Reportgenerator, Web-Frontend etc. sein. SQL ist so mächtig und performant, das ich darauf nicht verzichten möchte. Weiterhin ist SQL Standard und wer Standards in den Wind schießt, der kann das auch mit sich selber tun.

Der ganze Hintergrund wurde oben schon erklärt:

Zitat von Meine Wenigkeit:

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.

Wenn ich nun Daten abhole, dann geht das ja schlecht per SQL, also musste eine Abfragesprache entwickelt werden, die die Daten irgendwie lädt. hierzu wird ein Parser angeschmissen, der den Code der berechneten Felder interpretiert, dann die einzelnen Daten aus der Datenbank abholt, das ganze zu einer Tabelle/Objekt (ist eigentlich egal) verdichtet und dann zurückliefert.

So geht ja auch (Arbeiten nicht alle objektrelationalen Ansätze so?). Nur:
Wozu soll ich eine eigene Abfragesprache entwickeln (müssen), nur weil ich berechnete Felder und ein paar flexible 'Trigger' bzw. Setter möchte. SQL ist doch ideal dafür, die DBMS ist diesbezüglich optimal.

Versteht ihr? Ich habe etwas gegen eine Architektur, bei der eine Abfrage interpretiert wird, um sie dann (suboptimal) an das DBMS zu schicken, nur damit die das Selbe(!) in Grün mit der modifizierten Abfrage anstellt (interpretieren, Daten zusammensammeln, Resultat basteln, zurückliefern). Das da Redundanzen sind und die Performance in die Knie geht, ist doch logisch.

Im Zuge der zukünftigen Parallelisierung der CPU (wir reden nicht von 4 Kernen, sondern 400) sollte man sich Gedanken darüber machen, was man mit den brachliegenden Kernen eines DBMS nicht noch so alles anstellen kann.

Ich dachte mir, das man das Beste aus 2 Welten (DBMS und Hochsprachen) zusammenfassen kann, um eben so optimale Resultate zu erzielen. Natürlich steht dieser Ansatz im krassen Gegensatz zu z.B. den Erfahrungen von Elvis, der dafür plädiert, ein DBMS nur für nackte Tabellenverwaltung zu verwenden, und die gesamte Logik in einen separaten AppServer zu packen. Und gerade hier bekomme ich Bauchschmerzen. Aber aus rein ästhetischen Gründen (wie gesagt: redundante Systeme, Parser etc.). Mir fehlt die Erfahrung, um zu entscheiden, was letztendlich das beste Konzept (für die Implementierung einer Erweiterten Funktionalität in ein DBMS) ist.