Ich bin kein Fan von gespeicherten Prozeduren
Gespeicherte Prozeduren sind MEHR wartbar, weil:* Sie Ihre C#-App nicht neu kompilieren müssen, wenn Sie SQL ändern möchten
Sie werden es sowieso neu kompilieren, wenn sich Datentypen ändern oder Sie eine zusätzliche Spalte zurückgeben möchten oder was auch immer. Die Anzahl der Male, in denen Sie das SQL unter Ihrer App „transparent“ ändern können, ist im Großen und Ganzen ziemlich gering
- Am Ende verwenden Sie SQL-Code wieder.
Programmiersprachen, einschließlich C#, haben diese erstaunliche Sache, die Funktion genannt wird. Das bedeutet, dass Sie denselben Codeblock von mehreren Stellen aus aufrufen können! Tolle! Sie können dann den wiederverwendbaren SQL-Code in eines davon einfügen, oder wenn Sie wirklich Hightech wollen, können Sie eine Bibliothek verwenden, die das für Sie erledigt. Ich glaube, sie heißen Object Relational Mapper und sind heutzutage ziemlich verbreitet.
Codewiederholung ist das Schlimmste, was Sie tun können, wenn Sie versuchen, eine wartbare Anwendung zu erstellen!
Einverstanden, weshalb StoredProcs eine schlechte Sache sind. Es ist viel einfacher, Code in Funktionen umzugestalten und zu zerlegen (in kleinere Teile zu zerlegen) als SQL in ... SQL-Blöcke?
Sie haben 4 Webserver und eine Reihe von Windows-Apps, die denselben SQL-Code verwenden. Jetzt haben Sie festgestellt, dass es ein kleines Problem mit dem SQL-Code gibt, also ändern Sie lieber den Prozess an einer Stelle oder übertragen den Code auf alle die Webserver, installieren Sie alle Desktop-Apps (Klick kann helfen) auf allen Windows-Boxen neu.
Warum verbinden sich Ihre Windows-Apps direkt mit einer zentralen Datenbank? Das scheint genau dort eine RIESIGE Sicherheitslücke und ein Engpass zu sein, da es serverseitiges Caching ausschließt. Sollten sie sich nicht über einen Webdienst oder ähnliches mit Ihren Webservern verbinden?
Also 1 neuen Sproc oder 4 neue Webserver pushen?
In diesem Fall ist es Es ist einfacher, einen neuen Sproc zu pushen, aber meiner Erfahrung nach wirken sich 95 % der „gepushten Änderungen“ auf den Code und nicht auf die Datenbank aus. Wenn Sie in diesem Monat 20 Dinge auf die Webserver und 1 in die Datenbank schieben, verlieren Sie kaum viel, wenn Sie stattdessen 21 Dinge auf die Webserver und null in die Datenbank schieben.
Leichter Code überprüft.
Können Sie erklären, wie? Ich verstehe das nicht. Vor allem, da sich die Sprocs wahrscheinlich nicht in der Quellcodeverwaltung befinden und daher nicht über webbasierte SCM-Browser usw. aufgerufen werden können.
Weitere Nachteile:
Storedprocs leben in der Datenbank, die nach außen als Blackbox erscheint. Einfache Dinge wie der Wunsch, sie in die Quellcodeverwaltung zu versetzen, werden zu einem Alptraum.
Es gibt auch die Frage der schieren Anstrengung. Es könnte sinnvoll sein, alles in eine Million Stufen zu unterteilen, wenn Sie versuchen, Ihrem CEO gegenüber zu rechtfertigen, warum es ihn nur 7 Millionen Dollar gekostet hat, einige Foren zu erstellen, aber ansonsten ist das Erstellen einer gespeicherten Prozedur für jede Kleinigkeit nur zusätzliche Eselarbeit für nein profitieren.
