Hey Joe,

das ist mehr eine Design Frage, als eine technische. Das Kriterium ist hier Schichtentrennung und bei den heutigen (eher verteilten) Applikationen ist es relativ wichtig sowas strikt einzuhalten.
Auf den Datenbankserver gehört alles, was zur Datenbank gehört, also keine Geschäftslogik, die über Constraints hinaus geht.
In die Applikation gehört nichts, was mit Datenbank zu tun hat, also keinesfalls zusammen graben von Daten a la record level access mit read und chain und trulala. Innerhalb der Applikation weiss eigentlich nur die Datenbank Zugriffsschicht, dass es überhaupt eine Datenbank gibt.
Praktisch umgesetzt heisst das:
Alle lesenden Datenbankzugriffe erfolgen über Views und sind relativ elementar (select * from myView where myCondition).
Alle Datenzusammenhänge, wie Auftragskopf- Position, Kunde werden über entsprechende joins (views) abgebildet.
Das einzige komplizierte was jetzt noch überbleibt sind komplexere Transaktioenen beim Schreiben. (Sollbuchung, Habenbuchung, Kundensaldo). Da mag es Kandidaten für stored procedures geben, weil sich sowas in SQL leicht schreiben lässt; aber: sowas nagelt einen an die konkrete Datenbank!
Alles was Datenbankhersteller so erzählen, was an stored procedures so genial ist, hat genau das im Auge.
Einen Randbereich für SP gibt es noch auf der AS400: Einbindung von (vorhandenen) Komponenten; da sins dstored procedures das eleganteste, solange die as400 kein CORBA darf und das fürchte ich, wird so bleiben. Zudem habe ich bisher nur wenig in rpg Anwendungen gesehen, was man Komponente nennen könnte.
Was bei manchem Datenbankdesign schon eher gebraucht wird sind User defined functions, um Logik wieder in die Datenbank zu holen, die in die Applikation gerutscht ist, zum Beispiel: Ermittlung von Rechnungs Adressen, Frachtsätzen, zu faktorierender Kunde bei Konzernen etc.

mfg

Dieter Bender