Hallo sabse !
---
Lass bitte erst 'mal klaeren, ob ich das richtig verstanden habe :
"usr" "kunde"
- id + id
- stammdaten_id---- + firma
Dieser Link meint nicht das Feld "firma", oder ?
Sondern diese beiden
| + usr_id_betreuer
| + usr_id_kdzg
sind die Fremdschluessel, richtig ?
Die Tabelle "kunde" hat 2 Spalten die sich jeweils 1:n auf die Tabelle "usr" beziehen.
Aus deinem erlaeuternden Text und aus der Feldbenennung les ich n:1, also 1 Betreuer(in usr) hat n Kunden und
ein User/"kdzg" hat auch n Kunden.
War das so gemeint ?
Wenn das so ist, find ich den DB-Entwurf an der Stelle
o.k.
---
uu DB Designer
Der erstellt mir nämlich nur "usr_id" wenn ich eine Beziehung erstellen möchte Und umbenennen kann ich das dann auch nicht.
Um das FK-Feld umzubenennen kann man auf die Seite
der Link-Linie klicken die der "n"-Kardinalitaet
entspricht.
In der Mitte steht der Name des Dialogs steht
der Name des FK-Feldes.
Hab das mal gemacht (mit DBD 4.0.5.4 Beta)
und krieg sowas in der exportierten DDL Datei
[...]
CREATE TABLE kunde (
id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
usr_id_kdzg INTEGER UNSIGNED NOT NULL,
usr_id_betreuer INTEGER UNSIGNED NOT NULL,
PRIMARY KEY(id),
INDEX kunde_FKIndex1(usr_id_betreuer),
INDEX kunde_FKIndex2(usr_id_kdzg),
FOREIGN KEY(usr_id_betreuer)
REFERENCES usr(id)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
FOREIGN KEY(usr_id_kdzg)
REFERENCES usr(id)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);
[...]
War es das was Du wolltest ?
Macht es sinn auf beide einen Index zu legen?
EINFACH, (nicht-UNIQUE)
Ein Index macht i.A. INSERT langsamer aber
SELECT schneller.
Die betroffenen Tabellen scheinen Stammdaten zu
beinhalten - also i.A von mehr Lese- als
Schreiboperationen betroffen zu sein.
=> Index waere vielleicht sinnvoll, gerade da es sich
um FK handelt.
UNIQUE
Das wuede die Realationen jeweils zu 1:1 veraendern.
Dann sollte vielleicht das Design insgesamt neu
ueberdacht werden.