hallo
sorry - war zu ungenau bzw. habe dich falsch verstanden.
wenn deine adressen-tabelle nur den fk auf die firma hat und du diesen fk als pk definierst, kannst du nur eine adresse pro firma speichern. es sei denn, du definierst ein zusätzliches feld mit einer art zähler pro firma, die du zum pk dazuhängst.
mit einem eigenen pk und dem fk zusätzlich klappt es natürlich, beliebige adressen zur firma zu erfassen.
ach ja, einen composite pk aus praktisch allen spalten der tabelle zu machen, ist zumeist eher ungünstig. zumindest meiner erfahrung nach. ist leider schwer zu definieren: es gibt für beide ansätze (also ein künstlicher schlüssel oder ein oder mehrere natürliche schlüssel) für und wider. in meinen projekten war es bisher aber so, dass der aufwand, einen künstlichen schlüssel „mitzuschleppen“, recht gering ist. die probleme, die man aber ohne künstlichen schlüssel hat, teilweise einem über den kopf wachsen.
beispiel: meine anwendung basiert auf oracle und ist ursprünglich nur auf einem db-server gelaufen. dann kam eine zweite installation dazu, wobei die beiden installationen intensiv daten austauschen mussten. noch dazu kurzfristig, d.h. die anwendung umstellen war aussichtslos. also einfach per trigger alle änderungen an den tabellen mitprotokolliert und asynchron auf den jeweiligen anderen server verschickt. funktioniert überall prächtig, wo du einen künstlichen schlüssel hast und alle schlüssel in allen tabellen genau gleich heissen. bei einer tabelle habe ich mir den künstlichen schlüssel gespart und genau für diese tabelle musste ich einen workaround schaffen, der im endeffekt weitaus mehr aufwang gebracht hat, als das bisschen arbeit, dass ich mir ursprünglich gespart habe.
wenn deine anwendung recht klein ist, kannst du natürlich so überlegungen wie oben völlig ignorieren und wirst nie in ein problem reinlaufen. nur ich dachte bei meiner anwendung halt auch, dass sie recht klein ist und auch so bleibt…
lg
erwin
ps: präzisierung zum obigen problem mit den adressen: plz, ort und abgabestelle sind normalerweise ATTRIBUTE einer adresse. v.a. attribute, die sich grundsätzlich ändern können. solche attribute in einen pk aufzunehmen, ist immer gefährlich. der pk eines objekts solltes sich NIEMALS und unter KEINEN UMSTÄNDEN ändern. im endeffekt kommt man meist zu einem künstlichen schlüssel zurück, der absolut keine aussagekraft besitzt (ausser der, dass er eindeutig ist). da er keine aussage hat, kann er sich auch nicht ändern.
beispiel: bei personendaten wird gerne die svnr als pk herangezogen: die svnr ist per definition eindeutig und kann sich nicht mehr ändern.
denkste: die daten werden von sachbearbeitern eingegeben. und die machen tippfehler. natürlich kannst du über prüfsummen tippfehler vermeiden. aber dann kennt ein typ seine svnr nicht und gibt die seines vaters an - der vielleicht genau gleich heisst.
wir haben in unserem projekt das problem, dass wir auch ausländer erfassen müssen, die 1. keine svnr haben und 2. nicht mal ihr geburtsdatum wissen bzw. nachweisen können. für die werden offiziell (!) svnrn vergeben, die als datum den 01.13.09 beinhalten, also ein ungültiges datum - soviel zu prüfroutinen.
anderer klassischer fall: inzwischen gibt es derart viele geschlechtsumwandlungen, dass eine anwendung, die das geschlecht einer person nicht ändern kann, reichlich veraltet ist.
merke: nur weil er aus jetztiger sicht undenkbar ist, dass sich ein attribut einer person nicht ändert, heisst das noch lange nicht, dass es wirklich unmöglich ist. tippfehler und erfassungsfehler müssen jederzeit korrigierbar sein. scheinbar eindeutige attribute, die sich scheinbar nicht ändern können, als pk heranzuziehen, kann durchaus probleme machen.
geben wir der sache einfach ein neuen FirmenNamen ???