nicht angemeldet
Yo!
Hat man erst mal fuer ein neues Projekt die Anforderungen "zusammengetragen" so macht man sich an's Design des Datenmodells, welches hoffentlich den gewuenschten Teil der Realitaet abbildet.
Dann macht man sich an den Datenzugriff. Man ist ja schlau und verzichtet auf das Zusammenbasteln von SQL-Statements im "Programmcode" und auch auf den Einsatz von MS-empfohlenen Techniken (ADO, OOP, Serverprodukte von MS ausser 'MSSQL Server'), sondern gestaltet den Datenzugriff mithilfe von sog. Stored Procedures.
Dann hat man ein groesseres Rudel von "SET_", "GET_", DEL_", LST_" und "LET_"-Prozeduren, die sich allerdings langfristig (fuer Wartungszwecke z.B.) nicht leicht verwalten lassen. - Eine Trennung von Praesentation, Datenhaltung und Datenzugriff ist aber da.
Nun (endlich) die Frage:
Gibt es neben der o.g. Trennung nach Datenzugriffsform (CRUDL) weitere Vorschlaege zur Gruppierung (Namensgebung / Verwaltung) der Stored Prodedures? (Meine Versuche "Geschaeftslogik" von Datenzugriffslogik zu trennen, misslingen regelmaessig. Die Trennung von Praesentation, Datenzugriff und "Geschaeftslogik" habe ich allerdings "von Microsoft" gelernt.)
Gruss,
Lude