Frage zum DB-Design

[Cheatah]

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. Willst Du dies einem Entwickler nicht auferlegen, so stelle eine Schnittstelle zur Verfügung, die ihm diese Kenntnisse abnimmt.

Übrigens würde ich die Philosophie dahingehend abändern, dass er _maximal_ schlau sein sollte ... :-)

[1] Ein FK _zeigt_ zwar auf einen PK, aber [...]
Ich dachte Rechtschreibfehler und offensichtliche Versehen in der Sache werden hier nicht debattiert.

Daher ist dies ja auch nur eine Fußnote.

Ich hatte doch ein energisches und, wie ich finde, wohlbegruendetes Plaedoyer gegen zusammengesetzte PKs vorgetragen. Nicht mehr und nicht weniger.

Naja, wohlbegründet finde ich es nicht. Zumindest hat es mich nicht davon überzeugt, dass PKs nicht anhand der Eigenschaften der Daten gewählt werden müssten.

Und wenn man manchmal zusammengesetzte PKs als zulaessig durchgehen laesst und nur manchmal nicht, dann hat man natuerlich immer Diskussionsbedarf.

Zusammengesetzte PKs sind _immer_ zulässig und _meistens_ nicht sinnvoll. So einfach ist das :-)

Dann kommen auch die Freunde der Performance und der Komplexitaet zu ihrem Recht. Und genau das will man nicht in der Finanzdienstleistung, denn das rechnet sich nicht. (Zumindest solange ich hier noch etwas zu sagen habe!  ;-)

Nun ja, aufgrund von Prinzipien auf eine sinnvolle, mehr noch: notwendige Einstellung zu verzichten, trägt einen treffenden Namen: Broken As Designed, kurz BAD. 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.

Cheatah