Zahlen sich stored Procedures wirklich aus?

[Guest]

Bin ein bischen ein noob was DB angeht, aber für mein Praktikum muss ich mir halt auch einarbeiten.

Um auf meine DB zuzugreifen ist mir empfohlen worden stored Procedures zu verwenden da diese einfach schneller sein sollen. Das hab ich bis jetzt auch gemacht, aber wenn ich das in Java aufruf(call ...) dann frag ich mich ob sich die performance wirklich auszahlt? immerhin bekomm ich ja auch "nur" ein ResultSet zurück das ich weiter bearbeiten muss(oder mach ich da was falsch?)

 

[Caffè Latte]

Hi,

was hast du denn in den Prozeduren gespeichert? Um welches RDBMS handelt es sich? Wie sieht der Aufruf in deinem Java Programm aus?

Fragen über Frage ...

 

[spider_]

Hallo,

ich benutze stored procedure dann, wenn mehrere SQL statements an das dbms geschickt werden müssen und vielleicht noch vorher ein paar constraint-checks gemacht werden (beim INSERT z.B.). Beim INSERT ist es ja oft so, dass in mehrere Tabellen eingefügt werden muss, obwohl es aus Anwendungssicht ein INSERT ist. Dadurch kann ein wenig traffic gespart werden (vor allem, wenn viele Anwendungsprogramme darauf arbeiten) und es ist aus Anwendungssicht ein einziger Aufruf (externes Schema). Ich kann mir auch vorstellen, dass bei großen und häufigen SELECT anfragen, die vielleicht Statistiken generieren, es günstig ist, diese in eine stored procedure zu packen. Das dbms kann dann die prozedur schon "vorbereiten" wodurch der aufruf auch schneller gemacht wird.

 

[foobar]

Geschäfstlogik hat in der DB nichts verloren, auch wenn man dadurch etwas an Performance gewinnt.

 

[Lim_Dul]

Geschäfstlogik hat in der DB nichts verloren, auch wenn man dadurch etwas an Performance gewinnt.

Ab wann ist es denn keine Geschäftslogik mehr?

Die Datenbank wird ja nach dem Model designt. Da stecken eine Menge funktionaler Abhängigkeiten drin, die doch sehr stark mit der Geschäftslogik verzahnt sind. Oder ist das keine Geschäftslogik?

Eine eche Datenbank ist schließlich deutlich mehr als ein simpler Datenspeicher.

 

[semi]

We believe that database transactions against a single data source should never be started or
stopped outside of the database engine, even if the external code resides on the same machine
as the RDBMS.

Don't assume that all the advances made in RDBMS technology over the past 15 years
should be thrown out the window in favour of the wanton use of session or entity EJBs.
On the contrary, such a design approach is likely a recipe for disaster. In almost every case,
you will achieve maximum performance if you leave database processing to the database.

Quelle: BEA WebLogic Server Bible

Ich glaube, das ist Stoff für lange Diskussionen.

 

[foobar]

Ab wann ist es denn keine Geschäftslogik mehr?

Sobald es scih nur noch um Persistierung handelt. Ein Trigger beispielweise enthält Logik, da er weiß wenn Daten in Tabelle A eingefügt werden muß das und dass passieren. Mit Stored-Procedures verhält es sich genauso. Nicht umsonst werden die 3 Schichten streng getrennt. Durch Trigger und Stored Procedures wird das 3-Schicht-Modell zerstört und das ist nicht im Sinne des Erfinders ;-)

 

[Lim_Dul]

Sind denn dann Integritätsbedingungen nicht auch schon Geschäftslogik?
Also so Sachen wie jede Vorlesung muss genau einen Dozenten haben und ähnliches?

 

[foobar]

Also so Sachen wie jede Vorlesung muss genau einen Dozenten haben und ähnliches?

Doch aber das ist ja nur ein Fallback. Denn du kannst den Programmfluss nicht von einer Excpetion abhängig machen. D.h. du mußt sowieso in der Mittelschicht prüfen ob du gegen ein Constraint verstossen wirst, ansonsten knallt es.

 

[Lim_Dul]

So ganz überzeugt bin ich von deiner Meinung nicht, weil ich der Ansicht bin, dass diese Grenze, die du ziehst, nicht scharf ist. Andererseits hab ich noch mit einem Projekt zu tun gehabt, was in diese Kategorie fällt und ich weiß aus eigener Erfahrung, dass eine Sichtweise von außen, wie ich sie jetzt habe, häufig nicht alles erfasst, was man erlebt haben muss.

Andererseits muss man sehen, je nachdem, was man Stored Procedures verwendet, sind Fälle denkbar, wo der Performance Gewinn enorm ist, ohne das man wirklich Geschäftslogik einbaut.

Ich persönlich würde die Trenngrenze nicht an Triggern/Stored Procedures ziehen, sondern an der Stelle, wo automatisiert Daten von der Datenbank manipuliert werden um Geschäftslogik abzubilden. Solange jedoch Daten nur gelesen und besser zusammengefasst werden, würde ich das nicht umbedingt als Bruch sehen. Es mag durchaus Fälle geben, wo man die benötigten Daten nicht sinnvoll durch ein SQL Statement bekommt, dafür jedoch eine Stored Procedure anlegen könnte.

Aber wie gesagt, ich müsste erstmal selber in so einen Projekt Erfahrung sammeln, meine Ansichten sind momentan rein akademisch

 

[spider_]

Ab wann ist es denn keine Geschäftslogik mehr?

Sobald es scih nur noch um Persistierung handelt. Ein Trigger beispielweise enthält Logik, da er weiß wenn Daten in Tabelle A eingefügt werden muß das und dass passieren. Mit Stored-Procedures verhält es sich genauso. Nicht umsonst werden die 3 Schichten streng getrennt. Durch Trigger und Stored Procedures wird das 3-Schicht-Modell zerstört und das ist nicht im Sinne des Erfinders ;-)

Hallo,
ich bin nicht der Meinung, dass durch Trigger oder Stored Procedures das 3 Schichten Modell zerstört wird. Ich würde sogar eher sagen, dass es dadurch unterstützt wird. Denn duch Stored Procedures, wie auch durch Views, kann man die externe Schicht von der konzeptionellen trennen. Eigentlich sollte jeder Anwender seine Sicht auf die Daten haben, was ja im RDBMS durch Views realisiert werden kann. Wenn Daten eingefügt werden sollen, und es sich um eine durch JOINS zusammengesetzte View handelt (die dann nicht update-fähig ist), kann man in einer Stored Procedure Fälle bearbeiten, die das DBMS von "alleine" nicht wissen kann. Ich finde, dass Stored Procedures und Trigger ein gutes Mittel sind, um die Beziehungen der Daten zu realisieren, die man allein durch das relationale Modell nicht abdecken kann. Dabei ist es erstmal egal, was für eine Geschälftslogik später darauf aufgesetzt wird. Die Logik, die in Trigger und Stored Procedures enthalten ist, hat dann allgemeineren Charakter als die Geschäftslogik. Sie deckt schon fälle ab, die allein durch den Inhalt der Daten nicht auftreten sollen bzw. in der Realität nicht auftreteten dürfen.

Natürlich kann man in Stored Procedures auch viel zu viel Logik reinpacken, das sollte man aber nicht ;-)

 

[Guest]

Also so wie als noob das sehe ist das eine ansischtssache ob man stored procedurs verwendet, und performance mässig bringen sie wirklich nur dann was wenn mehr passiert als "nur" ein SELECT stimmt das so?

Den vorteil den sie haben aus java sicht, ich brauch die logik nicht in mein java programm packen und kann somit auch aus anderen Tools/Programmiersprachenohne probleme auf meine DB zugreiffen ohne mir gedanken machen zu müssen wie denn jetzt die DB aussieht!

Ist das jetzt so im groben richtig?

 

[foobar]

Also so wie als noob das sehe ist das eine ansischtssache ob man stored procedurs verwendet, und performance mässig bringen sie wirklich nur dann was wenn mehr passiert als "nur" ein SELECT stimmt das so?

Jepp

Den vorteil den sie haben aus java sicht, ich brauch die logik nicht in mein java programm packen und kann somit auch aus anderen Tools/Programmiersprachenohne probleme auf meine DB zugreiffen ohne mir gedanken machen zu müssen wie denn jetzt die DB aussieht!

In dem Fall wäre es sinvoller die Geschäfstslogik durch SOAP oder XML-RPC zu propagieren, dann können auch nicht Javaprogramme darauf zugreifen.