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.