nicht angemeldet
Hallo, Michael,
Man ist ja schlau und verzichtet auf das Zusammenbasteln von SQL-Statements im "Programmcode" ... , sondern gestaltet den Datenzugriff mithilfe von sog. Stored Procedures.
... sofern man kann. Und wenn ein RDBMS das nicht unterstützt, was dann?
(Ich habe nichts gegen dynamisch zusammengebastelte SQL-Statements - solange der "Bastler" selbst wiederum ein Modul ist.)
das Basteln von SQL-Statements hat u.a. den Nachteil, dass ausfuehrbarer Code vom Nutzer eingegeben werden koennte ('-- drop db...'). Ausserdem ist die Performance suboptimal. - Ansonsten kommt ein objektorientiertes Herangehen (Klassenmodule) in Frage und ist vielleicht zu praeferieren. - Aber ist es nicht wesentlich komplexer als ein Rudel SPs?
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.
Wie bist Du denn auf _diese_ Namen gekommen ... ?
Das waren Praefixe. Ist nach meiner Kenntnis auch ueblich.
Vorschlaege zur Gruppierung (Namensgebung / Verwaltung) der Stored Prodedures?
Was hältst Du davon, Dich von gängigen Adressierungsmethoden objektorientierter Sprachen inspirieren zu lassen?
("objektname"."methodenname", bzw. ein an dieser Stelle syntaktisch erlaubter Pseudo-Trenner wie "_")
OK, das scheint die Alternative zu sein. - Aber kann man dann auch mit vertretbarem Aufwand sicherstellen, dass eine Aenderung am Datenmodell den bisher implementierten Datenzugriff nicht zerstoert. - Ich meine, muss man dann nicht in jedem Modul schauen, ob der Code noch laeuft?
Gruss,
Lude