nicht angemeldet
Hi,
nach unserer Philosophie muss der Entwickler minimal wenig wissen und minimal schlau sein um bspw. einen Job zu erledigen. Einfachheit heisst die Devise, der wir folgen.
Kenntnisse der strukturellen Zusammenhänge _sind_ das Minimum an Wissen.
es geht auch darum dem Entwickler nur ein Minimum an Wissen um strukturelle Zusammenhaenge zumuten zu muessen.
Übrigens würde ich die Philosophie dahingehend abändern, dass er _maximal_ schlau sein sollte ... :-)
Gerade so schlau wie erforderlich, darum auch gut ersetzbar, nicht hinterhaeltig und kostenguenstig verfuegbar. So sieht der ideale Entwickler aus Sicht des Kaufmanns aus.
Nun ja, aufgrund von Prinzipien auf eine sinnvolle, mehr noch: notwendige Einstellung zu verzichten, trägt einen treffenden Namen: Broken As Designed, kurz BAD.
Mein Autokennzeichen faengt so an, meine Vorstellungen allerdings nicht. ;-)
Ich empfehle Dir, Richtlinien nur über Dinge zu treffen, deren Notwendigkeit Deiner Kontrolle unterliegt. Auf grundsätzliche Formen des DB-Layouts trifft dies definitiv nicht zu.
War nicht ganz ernstgemeint. Stenggenommen haben wir keine Richtlinien. Aber ich habe schon so viel Murks mit bedeutungsbelasteten PKs (zusammengesetzt aus drei Datenfeldern z.B.) aushalten muessen. Aber an meiner Empfehlung nie, zusammengesetzte PKs zu nutzen, halte ich dennoch fest.
Gruss,
Ludger