Ich versteh nicht ganz, was Du im Zusammenhang mit
FB und Stored Procedures unter Klassen und Prozeduren verstehst, aber ich kann ja mal aus dem Nähkästchen plaudern:
MSSQL, 100 Tabellen, ca 70 Stored Procedures.
Ich habe die Funktionalität der Mittelschicht ('Geschäftsregeln') peu a peu in die Stored Procedures verlagert. Das hat sich so ergeben, weil ich sonst kaum in einer 24/7 Umgebung Anpassungen machen kann.
Das Problem der 1000 Parameter pro SP habe ich umgangen, zumal sich die Parameterliste zur Laufzeit ändern kann. Alle Stored Procedures, die mit der Mittelschicht (was davon übrig geblieben ist) kommunizieren sollen, haben genau einen Parameter: Ein
XML-Record, bzw. eine proprietäre und kompaktere Variante. Damit muss ich die Mittelschicht nie mehr anfassen, nur weil ein Parameter hinzukommt. In den SP entpacke ich den
XML-Record und arbeite dann weiter. Eventuell wird der REcord erweitert und als Output-Parameter zurückgeliefert. Den zusätzlichen Overhead kann ich verkraften. Auch weil die
DB nicht am Anschlag operiert. Ausserdem ist Rechenpower günstig.
Nach 4 Jahren Dauereinsatz als Produktionsdatenerfasssung im 24/7 Betrieb einer grossen Fabrik lobpreise ich den Tag, an dem mir diese auf den ersten Blick ziemlich blöde Idee gekommen ist.
War das etwas Info für Dich?