Code in die Datenbank auslagern?

verwendetes Datenbanksystem: SQL Server 2005

Hallo!

Ich habe da mal eine generelle Frage an euch! Versucht ihr so viel Code wie möglich in die Datenbank auszulagern, wie z.B. Stored Procedures usw. oder lasst ihr sowas in eurem eigentlichen Programmcode?

Gibt es Vor- und Nachteile?

Vielen Dank!

Gruß
Echo

kommt meistens darauf an was.

prinzipiell versuche ich schon die datenbank eher logikfrei zu handhaben wobei die datenbank an unterster stelle (also quelle) der daten ist und daher in guter zentraler punkt ist. wenn z.b. 2 verschiedene programme teilweise gleiche funktionalität brauchen, da bietet es sich an eine SP zu schreiben und diese aufzurufen.

in abhängigkeit dazu stellt sich dannauch ncoh die frage, wo die datenbank ist. wenn sie auf einem server ist, der viel anderen traffic hat, dann versuche ich die SP vor ort die meiste arbeit machen zu lassen und somit den traffic nicht noch mehr auszulasten/überlasten.

und abschließend stellt sich noch die frage wie gut die datenbank hardwaretechnisch unterstützt wird (ram/cpu/anbindung) wenig ram und schwache cpu ist schlecht für große SP.

also ich sehe es individuell auf das problem und seine umgebung bezogen.

Alte DBA's behaupten immernoch, das SP's immer schneller sind, und deshalb
wollen die immer alles in SP's machen.

Das ist aber schon seit einigen Jahren nicht mehr der fall, wenn man
Parametrisierte Queries ( also mit ParameterCollection ) macht.

Es gibt eigentlich nur sehr weinige Sachen, die in einer SP noch wirklich sinn machen.
Audit Trigger vielleicht, und Sicherheits sachen.

Hallo,

Persönlich sehe ich die Datenbank nur und ausschließlich als Datenschicht einer Anwendung an, weshalb jegliche logik dort für mich nichts verloren hat!

Aber rein theoretisch gibt es euch viele gründe für das auslagern von Funktion in die Datenbank.

Gruß
Juy Juka

Stored Procedures ist die performanteste Lösung. Darauf zu verzichten wäre subobtimal.
Die meisten DBs haben eh ihre eigenen Vorlieben schon bei SQL-Abragen, bzw. Inkopatibilitäten zu bestehenden Standards. Also doch gleich zu SP greifen, wenn unterstützt.

Den WorstCase an krankhaften Design habe ich mal erlebt als tatsächlich die SQL-Abfragen in einer Tabelle der DB abgegt wurden. Schlimmer gehts nimmer.

Ich schlage vor ein DAL in mindestens 2 Layern aufzubauen(wenn DB-Unhabhängigkeit eine Rolle spielen sollte). Ein DB-spezifisches(unterstes) und ein oberes für die Umwandlung in richtige Objekte bzw. Listen derselben. Zwischenschichten könnten manchmal hilfreich sein.

Weiterhin schlage ich vor die DB-Updates für SPs und Tabellen/Contentänderungen nicht per mülligen Skripten manuell einzuspielen(jedenfalls nicht beim Kunden), das sollte Teil des Setups sein(mit Rollback natürlich).

@ikaros:
Streng genommen hast Du dann eigentlich 3 Layer, oder?

Stored Procedures --> DB-spezifischer Layer --> oberer "Objektumwandlungs"-Layer

Ich finde, das ist eine interessante Möglichkeit.
Das ganze Architektur- und Schichtenzeugs ist noch Neuland für mich, ich komme aus der Access-SQL Server-Ecke (mit exzessivem Gebrauch von SPs) und versuche mich gerade im .NET-Bereich zurechtzufinden.

Die meisten Sachen die man so zu dem Thema im Internet findet gehen ja meistens vom Standpunkt "SPs sind böse" aus und empfehlen NUR JA UNTER KEINEN UMSTÄNDEN SPs zu nutzen.
Für mich ist Deine Idee sehr interessant, vor dem Hintergrund daß ich eine große Anwendung habe und irgendwann mal Teile davon nach .NET migrieren möchte und es mir irgendwie widerstrebt meine ganzen fertigen SPs in die Tonne zu treten und neu zu schreiben.

@ikaros,

1. dafür gibt es dbproviderfactories. somit kannst du dich relativ datenbankunabhängig verhalten.
2. objektbildende schichten selber machen nur noch die steinzeit assemblerproggramierer. andere nehmen nhibernate oder ein der anderen 123123123 verfügbaren OR-Mapper und die meisten davon unterstützen mehrere datenbank-arten
3. der neue bzw eigendlich schon ältere trend heißt: "Datenbankunabhängig" . was gleichzudetzen ist mit "SP sind böse". die gründe hierfür liegen wohl auf der hand.
4. sp machen von daher nur sinn, wenn du
   a: die anwendung entlasten willst oder
   b: das netzwerk entlasten willst
   anderenfalls bist du bei einem datenbankumstieg besonders betroffen.

Persönlich sehe ich die Datenbank nur und ausschließlich als Datenschicht einer Anwendung an, weshalb jegliche logik dort für mich nichts verloren hat!

Aber rein theoretisch gibt es euch viele gründe für das auslagern von Funktion in die Datenbank.

Wieso soll das so sein? Der SQL 2005 Server bietet mittlerweilen .NET Unterstützung an, und damit lassen sich sehr wohl richtig komlexe Dinge direkt in der DB lösen. Die .NET Prozeduren können letzten Endes sogar die komplette mittelschicht ersetzen.

Ich hatte mal früher in einer Firma gearbeitet, da wurden ganze Produktionsanlagen inklusive dessen Lagerverwaltung REIN über den SQL Server gemanaged. Und das sogar noch zu Zeiten von SQL 2000.

Man sollte nicht immer alles glauben, was einem so vorgegaukelt wird. Wenn eine Lösung stabil und lagfristig funktioniert, und dabei auch noch flexibel bleibt, dann ist sie gut, und es braucht nicht immer irgendwelche neuen Technologien, die in erster Linie oft nur deswegen eingesetzt werden, weil sie neu sind.

Besagte Firma haben Produktionsanlagen am Laufen, die über 5 Jahre störungsfrei 24/24 laufen.

Hallo,

ich packe eigentlich relativ viel in SPs. Und ja, auch Programmlogik. Das hat aber den Grund, das bei verschiedenen Kunden auch verschiedene Abläufe stattfinden müssen. Um nicht jeden Kunden eine spezielle Software zu geben, was irgendwann in Chaos führt, sind einige Programmabläufe halt im Server ausgelagert.
Das hat den riesen Vorteil, das wenn der Kunde auf einmal auf den wilden gedanken kommt, das jetzt doch was anderes bei Schritt x passieren soll, man es relativ leicht und ohne Softwareanpassung ändern kann.
Ebenfalls sind sämtliche SQLs für die Reports als SP abgelegt um Änderungen am Report ebenfalls ohne Softwareänderung durchzuführen. Es ist sogar möglich komplett neue Reports in die Datenbank anhand von SPs zu legen.

Darum denke ich, das man auf keine Fall unüberlegt sagen sollte: "Benutzt bloß keine SPs". Es kommt auf den Anwendungsfall an.

Ebenfalls sind, wie Jelly schon sagt, ja mittlerweile .NET Assemblies im Server möglich. Die Möglichkeiten sind also enorm geworden.

Und noch was anderes. Wenn man komplett sagt, ich benutze die DB nur als reinen Datenspeicher, braucht man kein SQL Server. Warum? Weil man das Potential des SQL Servers dann vielleicht gerade mal zu 1% nutzt.

Und noch was anderes. Wenn man komplett sagt, ich benutze die DB nur als reinen Datenspeicher, braucht man kein SQL Server. Warum? Weil man das Potential des SQL Servers dann vielleicht gerade mal zu 1% nutzt.

Was braucht man denn dann stattdessen?

Was braucht man denn dann stattdessen?

Es ging mir bei der Aussage nur darum, das es sehr sehr viele Datenbanken gibt (und die Software dazu), die fast null Features vom SQL Server verwenden. Da frag ich mich immer warum? Nur weil halt irgendwo steht "Nee, benutzt bloß keine SPs oder SFs. Und ja nie Logik in der DB". Solch Aussagen find ich halt übertrieben.

Das Potential, welches der SQL Server bietet sind enorm. Sehr enorm.

Achja und zu deiner Frage: Wenn man sicherlich sehr große Datenvolumen hat, macht ein SQL Server natürlich Sinn, auch wenn man dessen Features nicht nutzt. Aber bei kleineres Projekten, oder eher kleineren Datenvolumen, würde ich dann kein SQL Server nehmen, sondern eher Firebird. Allein aus Lizenzkosten.

Stored Procedures ist die performanteste Lösung. Darauf zu verzichten wäre subobtimal.

So eine Pauschalaussage ist Quatsch. Wie weiter oben schon gesagt sind Abfragen mit Parametern min. ähnlich performant, wenn nicht genauso schnell.

Moin,

Die .NET Prozeduren können letzten Endes sogar die komplette mittelschicht ersetzen.

Das ist genau das Problem! Es gibt nicht umsonst eine Teilung in mehrer Schichten und wenn man das Konzept von StoredProcedures (egal ob in PL/SQL, T-SQL oder C# geschrieben) verwendet, dann verstöst man gegen das Schichten-Model und handelt sich Protierungs-, Wartungs- und Erweiterungsprobleme ein (kann natürlich von Vernachlässigbar bis Tötet-Das-Projekt reichen, aber ist und bleibt gefährlich)

Gruß
Juy Juka

Das ist genau das Problem! Es gibt nicht umsonst eine Teilung in mehrer Schichten und wenn man das Konzept von StoredProcedures (egal ob in PL/SQL, T-SQL oder C# geschrieben) verwendet, dann verstöst man gegen das Schichten-Model und handelt sich Protierungs-, Wartungs- und Erweiterungsprobleme ein (kann natürlich von Vernachlässigbar bis Tötet-Das-Projekt reichen, aber ist und bleibt gefährlich)

Ich hab ja auch nicht gesagt, dass das in allen Fällen die beste Lösung ist, sondern ein Beispiel gegeben, wo es definitiv Sinn machte (es war keine Produktionsanlage wie die andere).

Und trotzdem behaupte ich, dass das Auswechselen einer SP (ob in .NET oder T-SQL) genauso leicht geht wie in einer anderen Middleware ein paar Objekte auszutauschen. Aber du hast natürlich Recht, pauschal kann man nicht sagen, dass alles über SP's abgewickelt werden kann oder soll.

Und was ist bitte letzten Endes eine SP anderes, als eine Mittelschicht. Sie liegt eben nur direkt in der Datenschicht mit drin, agiert aber eigenständig. Dem Client ist es letzten Endes egal, ob ihm eine Funktionalität über eine Remoting Objekt oder eine SP zu Verfügung gestellt wird (mal abgesehen von der objektorientierten Vorgehensweise, aber das ist ja nicht die Thematik). Das einzige, was letztlich verloren geht, ist die Datenbankunabhängigkeit. Aber auch das ist in den wenigstens Fällen von Bedeutung (unsere Kunden haben den SQL Server hingestellt bekommen, und gut war). Natürlich, wenn man Software für unterschiedliche DBMS entwickeln muss, kommt man mit der Logik in den SP's natürlich nicht weit. Aber das ist ja von Fall zu Fall unterschiedlich.

@Jelly
deiner aussage nach könnte man ja die bl in eine form packen und die datenschicht in die datenbank, dann greifen wir noch am besten aus der klickmethode direkt in die datenbank.....
(auch das ist jetzt übertrieben ausgedrückt)

klar ist es differenziert zu betrachten, was sp anbelangt aber jegliche pauschalaussage dürfte unangebracht sein.

wenn man viele kunden hat, die gerade in bestimmten abläufen an der datenabnk änderungen haben wollen, dann macht das sinn, wenn man weiß das man so oder so die datenbank nicht ändern muss.

wenn man kunden hat, die alle unterschiedliche datenbanken haben und sich keine neue zusätzliche leisten wollen dann sind SP´s das KO kriterium.

ansonsten gild noch das performanceargument das ich in meinem ersten post erwähnt habe. schwacher db-server ist ein kontra, möglichst wenig traffic verursachen ist ein pro.

was noch hinzukommt sind die kleinen tücken und besonderheiten des individuelen projektes (manager, kunden, bwl-entscheidungen und produktpolitik die keine ahnung von software haben)

deiner aussage nach könnte man ja die bl in eine form packen und die datenschicht in die datenbank, dann greifen wir noch am besten aus der klickmethode direkt in die datenbank.....
(auch das ist jetzt übertrieben ausgedrückt)

Naja, das ist aber jetzt wirklich etwas überspitzt ausgedrückt. Immerhin würde bei mir die BL noch in einem Server liegen, und nicht im Client und schon gar nicht in dessen GUI. Also den Vergleich lass ich aber jetzt nicht durch 😁

klar ist es differenziert zu betrachten, was sp anbelangt aber jegliche pauschalaussage dürfte unangebracht sein.

wenn man viele kunden hat, die gerade in bestimmten abläufen an der datenabnk änderungen haben wollen, dann macht das sinn, wenn man weiß das man so oder so die datenbank nicht ändern muss.

wenn man kunden hat, die alle unterschiedliche datenbanken haben und sich keine neue zusätzliche leisten wollen dann sind SP´s das KO kriterium.

ansonsten gild noch das performanceargument das ich in meinem ersten post erwähnt habe. schwacher db-server ist ein kontra, möglichst wenig traffic verursachen ist ein pro.

was noch hinzukommt sind die kleinen tücken und besonderheiten des individuelen projektes (manager, kunden, bwl-entscheidungen und produktpolitik die keine ahnung von software haben)

Zu all diesen Punkten geb ich dir bedingungslos Recht: 👍

Moin Moin,

wollte auch noch meinen Senf dazu geben:

zu behaupten Prameterisierte Querys wären genauso performant wie SP's ist falsch. Warum? Ganz einfach: Beim ersten Aufruf einer Query muss ein Ausführungsplan erstellt werden, der bleibt eine gewisse Zeit im Cache und kann wiederbenutzt werden. Wenn er aus dem Cache fliegt dann muss der Ausführungsplan wieder neu erstellt werden. SP's liegen schon kompiliert vor. Ergo ergibt sich hier immer ein (kleiner) Performance Nachteil für Querys.

Security: Bei all dem SQL-Injection-Zeug (wobei ich hier auch immer parameterisierte Querys empfehle) wird übersehen, dass wenn man gleich SP's einsetzt, man den Usern nur noch Zugriff auf die SP erlauben braucht, aber ansonsten keine Rechte einräumen muss. Damit hat man im Endeffekt den besten Schutz für seine Daten.

In den SQl-Server eingelagerte .net-Assemblys (also das was weiter oben "SP's in .Net geschrieben" genannt wurde) sind von der Performance nicht mit echten SP's zu vergleichen, da ja wiederum erst eine Query an den Server abgesetzt wird. Allerdings sind hier die Möglichkeiten wesentlich umfangreicher als mit reinem T-SQL.

Auf Gegebenheiten wie JAck30lena sie oben erwähnte (Ram/CPU des Servers usw.) würde ich mich beim Design nie einlassen. Es gibt für mich fast nichts schlimmeres, als ein SQL-Server der zu wenig Ram hat, weswegen sich die CPU langweilt weil die ganze Zeit Daten von der Platte geholt werden müssen. Und dann wundert man sich, dass man keine Performance aus dem Ding holt. Allerdings kann man sich durchaus überlegen, ob man nicht bei Client Applikationen etwas mehr von den Daten zwischenspeichert und so den Traffik zum Server reduziert.

🙂

Xynratron

Auf Gegebenheiten wie JAck30lena sie oben erwähnte (Ram/CPU des Servers usw.) würde ich mich beim Design nie einlassen.

da bin ich gespannt wie du das dem kunden und deinem chef erklärst, wenn der chef seine software nciht verkaufen kann weil seine kunden eher schwache datenbanken haben oder der kunde der sich extra für diese eine applikation einen neuen server leisten muss.

sagst du da: "per design nicht anders möglich" nur weil es deiner meinung nach schöner und sicherer ist ?

Ich halte es für eine best practice soviel wie möglich von der Datentransformations- und Zugriffslogik in die Datenbank selbst zu packen (oder in irgendeine Mediator-Schicht).

Sowas hat im Client nichts verloren und man kann schnell und zentral Änderungen durchführen ohne Software neu verteilen zu müssen.

Aus meiner Erfahrung heraus kann man einem Kunden nicht seine eigenen Anforderungen aufzwingen. Man kann aber bei der Angebotsphase entsprechende Vorschläge durchführen und dann mit dem Kunden zusammen entscheiden welche im Moment die beste Lösung für den Kunden ist.

Alles andere ist in diesem Zusammenhang nicht relevant. Der Kunde will meist schnell und unkompliziert eine Lösung haben und diese darf nicht das entsprechende Budget übersteigen.

Ob es nun Sinn macht oder nicht SPs zu benutzen, muss man in jedem Projekt selber entscheiden. Das ist die gleiche Frage wie ob man ein ORM benutzen soll oder nicht.

Erstmal vielen Dank für eure Antworten! (ich schein ja eine größere Diskussion angezettelt zu haben! 😉 )

Da ich mich mit diesem Thema erst jetzt so richtig beschäftigen muss, habe ich nochmal eine Frage:

Wie sieht es denn aus, wenn ich mehrere Sachen in die DB auslagere und der Kunde nachher ein Patch oder Service Pack des SQL Servers installiert, gab es da schonmal Probleme oder könnte es zu Komplikationen kommen?

Gruß
Echo

Ich hatte noch nie Probleme nach einem Service Pack für den SQL Server.

Ich halte das seit Jahren so, dass die größt mögliche Anzahl an Logik in die Datenbank kommt. Allein schon von der Geschwindigkeit her bringt das Vorteile und der Code im FrontEnd bleibt schlank und lesbar.

Allein schon von der Geschwindigkeit her bringt das Vorteile und der Code im FrontEnd bleibt schlank und lesbar.

das ist ein märchen...

1. der code bleibt gleich groß da der code in der datenbank zur anwendung zählt und mitgelesen werden muss. wenn du ihn schlank halten willst dann teile ihn doch auf mehrere dll´s und klassen auf. nicht anderes machst du wenn du ihn in die datenbank auslagerst
2. schnell ist relativ. hängt sehr vom netzwerk und von der hardware ab.
3. das ist wiedermal so eine pauschalaussage...

was patches und service packs betrifft, so habe ich auch bislang nicht wirklich von problemen gehört. ist es allerdings eine datenbank die nciht ausfallen darf, so sollte man vorher gründlich testen, wob nicht doch irgendwelche fehler nach der installation auf dem produktivsystem auftreten könnten. zu erwarten sind allerdings in der regel keine fehler.

Je mehr Antworten ich hier lese, desto mehr weicht die Gesamtaussage dieses Themas von dem ab was ich bisher so im Internet in der Richtung gefunden habe.

Da sogar diejenigen von euch die Anwendungen für Kunden entwickeln zur großen Mehrheit SPs etc. als Datenschicht benutzen, wollte ich hier doch nochmal kurz meine Situation zur Diskussion stellen:

• Angestellter in einem mittelständischen Industrieunternehmen (also kein Softwarehaus o.ä.)
• ich entwickle NUR Software für den firmeninternen Gebrauch (Verkauf, Produktkonfiguration, Produktion...)
• ALLE Datenbanken die es bei uns gibt laufen unter MS SQL Server 2005
• Software bis jetzt ist ein Access 2003-Frontend (also nix mit OOP und Schichtentrennung) mit exzessiver SP-Nutzung
• schrittweise Umstellung auf .NET ist angedacht, aber noch nicht mal angefangen

Vor diesem Hintergrund und der Tatsache daß ich meine ganzen schönen SPs ungerne neu schreiben möchte - das bedeutet für mich doch "alles in die DB was geht", oder?
Wir experimentieren auch gerade mit NHibernate, aber falls das nix wird wäre der beste Ansatz für die Datenschicht wahrscheinlich der folgende:

Datenschicht "unten":
SPs

Datenschicht "oben":
SPs in "richtige" Objekte umwandeln (bzw. direkten Tabellenzugriff für Bereiche wo es keine SPs gibt, bei denen SPs eher ungeeignet sind usw.)

@haarrrgh: Das wichtigste wäre, alles gleich zu lösen, also nur SPs oder gar keine SPs. Das schlimste für eine Software ist es, wenn alles immer wieder anders gemacht wurde. So eine Software ist nicht wartbar!
Ich gehör zur 0-SP-Fraktion, würde dir also auch zu keinen SPs raten g ist aber Subjektiv.
SPs wären für eine Firmen-Interne Software vielleicht nicht schlecht.

DBA's bevorzugen SP's und Views, weil sie so die Daten vor den bösen
Anwendern und Programmierern schützen können.

Für die reine Entwicklung selbst hoch Datenbanklastiger Anwendungen sind sie
aber im Grunde nicht mehr notwendig.

Es gibt aber immer Grenzbereiche, wo sie Sinn machen ( Auditlog Trigger z.b.).

Aber mit NHibernate ( ActiveRecord nicht vergessen ) ist beides leicht benutzbar.

Auf www.codeproject.com gibt es einen guten Artikel zu den Bestpractice mit NHibernate.

Auf Gegebenheiten wie JAck30lena sie oben erwähnte (Ram/CPU des Servers usw.) würde ich mich beim Design nie einlassen.

da bin ich gespannt wie du das dem kunden und deinem chef erklärst, wenn der chef seine software nciht verkaufen kann weil seine kunden eher schwache datenbanken haben oder der kunde der sich extra für diese eine applikation einen neuen server leisten muss.

und abschließend stellt sich noch die frage wie gut die datenbank hardwaretechnisch unterstützt wird (ram/cpu/anbindung) wenig ram und schwache cpu ist schlecht für große SP.

@JAck30lena:

Hi, sorry dass die Antwort etwas warten lies^^

Ich greif mal deine Aussage auf und gebe Dir unumwunden recht dass "wenig ram und schwache cpu ist schlecht für " Datenbanken im allgemeinen sind. Wenn wir jetzt die SP erstmal aussen vor lassen und einen Server mit schlechter Performance haben, dann sieht das Problem meiner Erfahrung nach meist so aus:
Die CPU hängt bei 0%, der Arbeitsspeicher ist zu 100% voll und die Platten laufen heiss. Die Cache-Hit-Ratio ist auch ziemlich miserabel. Die Datenbank an sich hat vielleicht 4 GB und der Server ist ein älteres Baujahr mit 1 GB Ram. Problemlösung: dem Server einfach mal 4 GB Ram spendieren, dann kann er die DB praktisch komplett im Speicher halten und muss nur zum schreiben von Daten auf die langsamen Platten zugreifen. Tja, und ab hier könnte man SP einsetzen und mehr Rechenzeit auf die immernoch brachliegende CPU schieben.

Und vor diesem Hintergrund würde ich nie eine (große) DB Designen, bei der ich darauf achten muss, dass der Kundenserver sehr "mager" ist. Oder anders ausgedrückt: Ich würde schon bei den ersten Besprechungen darauf hinweisen, da es hier zu Performanceproblemen kommen kann. Man kann dann immernoch verschiedene Lösungsansätze versuchen (kommt ja auf die eigentliche Aufgabe an), z.B. Buchhaltungsprogramm nach einem Jahresabschluss alle Daten in eine zweite DB auslagern, Indextabellen je nach Nutzung auf verschiedene Datenbank-Files verteilen, dass immer nur die "viel genutzen" im Arbeitsspeicher liegen. usw.

DBA's bevorzugen SP's und Views, weil sie so die Daten vor den bösen
Anwendern und Programmierern schützen können.

Tja ich komm aus der DBA-Ecke und muss sagen: hättet ihr mal auf uns gehört, dann würde kein Programmierer das Wort SQL-Injection kennen^^

Aber Spass beiseite: Wenn man parameterisierte Querys einsetzt hat man eigentlich kaum mehr die Notwendigkeit einer SP.

🙂

Xynratron

Habe ich mir gedacht.

Ich habe beide seiten kennengelernt ( habe deshalb mal den MCDBA machen müssen )
und kann deshalb immer gegen beide Auffassungen "Wettern".

Es ist wie beim Appserver.
Das ist ein schönes konzept, Scaliert besser als eine reine Sql-Server ( fabrikat egal )
Lösung, aber wer braucht das?
Es ist sicherlich richtig, das Lösungen für zig GB Datenbanken bedeutende Planung und
Resourcen benötigen, am falschen Ende Sparen ist da nicht gut, aber auch
hier ist die Frage, wer das braucht.
Firmen, die diese Datenmengen haben, haben eben DBA's, der Feld/Wald/Wiesen
Benutzer reizt meisst den Sql-Server Express und seine max 4GB
Datenbanken nicht aus.

Mann sollte nur hier nicht wie andere immer in Dogmen verfallen.

Und, wenn Menschen vernünftig wären, bräuchten wir viele Sachen nicht 😉

Ich wollte nur noch anmerken, dass SPs oft einen Sinn machen. Wer z.B. meint riesige Insert Selects mit zig Aggregationen oder sonstige Transformationen und komplexere Transaktionen vom Client aus steuern zu müssen statt sie in ein SP zu packen und selbige zu callen ist ganz klar auf dem Holzweg.

Wer z.B. meint riesige Insert Selects mit zig Aggregationen oder sonstige Transformationen und komplexere Transaktionen vom Client aus steuern zu müssen statt sie in ein SP zu packen und selbige zu callen ist ganz klar auf dem Holzweg.

Ich denke hier redet keiner davon, solche Sachen direkt vom Client aus zu steuern. Das dürfte jedem einleuchten. Vielmehr geht es doch darum, ob solche Datenmanipulationen direkt von einer SP oder von einer Middleware durchgeführt werden sollen.

@Harg:
Bei strenger 3-Achichtenarchitektur(Nichrt dieses N-Dings-Gelaber), geht man tatsächlich von Client, Middleware und Datenhaltung aus.

Jede dieser Schichten hat nehr oder minder "Intelligenz". ZB- hat eine OracleInstanz mehr Möglichkeiten, aber auch Fallstricke.
Ein Access ist eine tolle Sache für lokale Datenhaltung, minder Geeignet für zentrale Sachen(der Reportbuilder ist toll und kostengünstog wie kaum andere).
Oracle insbesondere und MSIgitt( 😉 ) mögen als untere Schicht nicht sonderlich deiner Anwendung geneigt sein, sondern nur irgendwie Selbstzweck. Dafür gibt es ja in der Anwendung selbst die 3. Schicht(Wenn es der Aufwand denn wert ist). Ganz einfach um den Schmutz austauschen zu können. Heute Access, morgen Oracle. Beide DBs sind Beispiel für Scghmutz, dh. beide halten sich nicht an Standards.
Nimmt man noch den SQL-Server dazu oder das mySql-Ding, wird man feststellen das mit den sogenannten Standards nichts gewonnen ist.
Nich desdestotrotz wird deine App, nicht täglich die DB-wechseln(beim Kunden), Deine Kunden versehentlich jedoch verschiedene DB's als ihr Haustier ansehen.
Deshalb sehe ich es als gut an den "Schmutz" zu abstrahieren und die unterste Schicht austauschbar zu machen, und das perfekt auf das eigentliche Datenlayer.
Genaugenommen also die Auftrennummung der 3. Schicht deiner Anwendung auf Hi & Lo Dal.
Es gilt auch hier: Divide et Imperia.