PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Tabellen verknüpfen



jamesplate
14-11-2006, 14:10
Hallo,

hab schon wieder eine Frage.:confused:

Ich habe zwei Tabellen, in der einen stehen jeweils die Firmen mit Adresse und in der anderen die Ansprechpartner der jeweiligen Firma.
Wie kann ich diese zwei Tabellen verknüpfen?
Ich möchte, dass das Feld Adr_ID (kein Primär-Schlüssel) von Tabelle Ansprchpartner den selben Wert wie die ID (Primär-Schlüssel) von den Firmenadressen hat, wenn die jeweilige Person tatsächlich der Ansprechpartner der Firma ist, sodass da eine Verbindung besteht und ich dies dann gezielt in meine Warenwirtschaft einbauen kann.
Wie mach ich das? Brauche ich da PHP oder kann ich sowas einfach nur alleine mit mysql hinbekommen?

Gruß

mwanaheri
14-11-2006, 17:31
So was macht man in SQL mit einem join;
select * from firmentabelle
join ansprechpartner on ansprechpartner.adr_id = firmentabelle.id;

So werden dir alle Fälle angegeben, wo zu einer Firma ein Ansprechpartner vorhanden ist. Willst du auch die Firmen, zu denen es keinen Ansprechpartner gibt, brauchst du einen left join, also
left join ansprechpartner...

jamesplate
15-11-2006, 09:43
Hallo, vielen Dank erstmal für die Antwort,

aber die Problematik ist etwas anders, da bringt dich deine Antwort einfach nicht weiter! Vielleicht kannst du Dir ja jetzt besser vorstellen was ich meine..


Tabelle ADRESSEN:

ID Fimenname Straße PLZ .....
1 Mercedes Xy Xy .....
2 BMW Xx Xx .....
3 Porsche Zz Zz .....
.... .. .... ..... .....
.... .. .... ..... .....
Tabelle ANSPRECHPARTNEER:

ID Addr_ID Name Vorname Userfeld 01
1 Meier Horst Porsche
2 Müller Hans Porsche
3 Heinz Philipp Mercedes
.... .... ..... .....
.... .... ..... .....
Die ID ist jeweil
Primärschlüssel!
Aufgabe:
Wenn das Userfeld 01 von Tabelle ANSPRECHPARTNER (ASP) mit dem Firmennamen(Feld) aus Tabelle ADRESSEN übereinstimmt, dann soll die Addr_ID von ASP (is ja kein Primärschlüssel) den dazugehörigen Wert der ID aus Tabelle ADRESSEN erhalten.

Also in dem obigen Bsp müsst jetzt in Tabelle ASP in der Spalte Addr_ID übeall eine 3 stehen, wenn in Spalte Userfeld 01 Porsche steht (also die ersten zwei) und eine 1 stehen, wenn in der Spalte Userfeld 01 Mercedes eingetragen ist.

Da bei dem Warenwirtschaftssystem schon eine Verbindung zwischen den Feldern
ADRESSEN.ID und ASP.Addr_ID besteht muss ich das irgendwie so hinbekommen.

mwanaheri
15-11-2006, 10:06
Woher kommt deine Fixierung auf Primärschlüssel? Die sind für einen Join ziemlich wurscht. Auf den Datentyp kommt es an. Die Sinnfrage beim Join musst du beantworten, nicht die Schlüssel.

Die Lösung heißt hier:
select ansprechpartner.id, adressen.id AS Addr_ID, Ansprechpartner.Name, Anprechpartner.vorname, Ansprechpartner.Userfeld 01
from Ansprechpartner
JOIN adressen ON ansprechpartner.Userfeld01 = adressen.firmenname;

Nochmal: Ein join muss sich nicht auf ein Schlüsselfeld beziehen, auch, wenn das meistens sinnvoll ist.
Falls die Tabelle Ansprechpartner bereits besteht und ein ungenutztes Feld Addr_id hat, wäre hier ein update sinnvoll. Das setzt allerdings eine Unterabfrage voraus. Sollte MySQL aber auch können.

jamesplate
15-11-2006, 11:51
Also ich hab mit Sicherheit keine Fixierung auf Primärschlüssel, wollte nur mitteilen, was die Primärschlüssel sind, man könnte ja meinen, dass Addr_ID Primärschlüssel ist, stattdessen ist aber ID der Primärschlüssel in der Tabelle ASP! Das war alles was ich damit meinte.
Mir ist selber vollkommen klar, dass es join egal ist ob nun Primärschlüssel oder nicht.
Ich glaube, du verstehst die Problematik noch immer nicht. Es besteht bereits ein Warenwirtschaftssystem! Eine Verknüpfung zwischen Addr_ID in ASP und ID in ADRESSEN besteht bereits, die kann ich nicht verändern.
D.h. wenn der Mitarbeiter xy im Programm auf Adressen eine Firma anklickt zeigt es jeweil die entsprechenden ASP! Nur sind da paar dazugekommen bzw. sind bei der Falschen Firma! Ich möchte das jetzt neu zuordnen.
Da hilft mir der JOINT Befehl herzlich wenig, da dieser nur kursfristig ist und keine Änderung der eigentlichen Datenbank bringt. Auch hilft mir eine dritte Tabelle nichts.

Gruß

jamesplate
15-11-2006, 13:53
So was in der Art brauch bzw. Suche ich:

Hab schnell mal ein Skript geschrieben, es funktioniert aber nicht, es zeigt keine Fehlermeldung an, es passiert aber auch nichts.

<?php

$db=mysql_connect („IP-Adresse,“user“,“web“);

$anfrage1=mysql_db_query(„cao_lb“,“select * from ADRESSEN“);
$anfrage2=mysql_db_query(„cao_lb“,“select * from ADRESSEN_ASP“)

$ergebnis1=mysql_num_rows($anfrage1);
$ergebnis2=mysql_num_rows($anfrage2);

echo „$ergebnis1 Datensaetze in ADRESSEN <br> und $ergebnis2 Datensaetze in ADRESSEN_ASR gefunden<br>“;


// eigentliche Programm startet

for ($i=0; $i <= $ergebnis1; $i ++)
{
for ($j=0; $j <= $ergebnis2; $j ++)
{
if (mysql_db_query(ADRESSEN.Firma == ADRESSEN_ASP.USERFELD_01);

{
mysql_db_query („UPDATE ADRESSEN_ASP SET ADDR_ID = ADRESSEN.REC_ID“);
}
}
}

mysql_close($db);

?>

cao_lb heißt die DATENBANK
irgendwo bei if muss der Fehler liegen!!

mwanaheri
15-11-2006, 17:01
Also erst mal vorab: Die Datenbank dieses Warensystems hat offenbar ein paar Strukturelle Probleme:
- sie ist nicht ordentlich normalisiert
- sie führt nicht genügend Prüfungen durch (hier fehlt ein Fremdschlüssel!)
- die GUI verwendet Handeingaben, wo Auswahlen stehen sollten.

Ansonsten würde ich das Problem nicht mit php angehen, sondern mit sql. Das sollte etwa so aussehen:
UPDATE ansprechpartner
SET addr_id = (SELECT id FROM addressen WHERE adressen.firmenname = ansprechpartner.userfeld01)

Aber: Ist eigentlich sichergestellt, dass jeder Firmenname nur einmal vorkommt? Und wenn nicht, wie willst du das im Zweifelsfall entscheiden?

Sollte die Gefahr bestehen, dass bei den Ansprechpartnern Firmen eingetragen sind, die in der Adressliste nicht vorhanden sind (addr_id ist dann null), so kriegst du das raus mit
select * from ansprechpartner where addr_id is null and userfeld01 is not null;

jamesplate
16-11-2006, 11:24
Ok, ich hab das Problem gelöst!!

Mit einem ganz einfachen UPDATE ... Where Befehl hat es funktioniert, aber nur da ich mein 3.23.58 MySQL erneuert habe und jetzt ein 4.1.* MySQL habe! Damit habe ich jetzt wesentlich mehr Möglichkeiten!
z.B. ein UPDATE-Befehl der sich ohne JOIN über zwei (oder mehrere) verschiedene Tabellen erstreckt und endlich sind auch Unterabfragen (Subqueries) , Verschachtelungen ohne Probleme möglich, sodass ich mir hier wesentliche Verbesserungen geschaffen habe und die Dinge einfacher zu handhaben sind.
Das Select im UPDATE Befehl, wie bei deinem Vorschlag, brauch man nicht, geht ohne besser!

So nun zu den angeblich strukturellen Problemen:

natürlich ist die Datenbank ordentlich normalisiert, wie kommst du auf die Idee, dass sie das nicht sei? Nur weil sie Handeingaben zulässt? Ist das immer gleich ein Fehler, wenn nicht alles automatisiert ist?
Ich denke nicht!!
Wenn jede kleine Firma eine komplett automatisierte Datenbank hätte, so würde sie sich doch von externen Informatikern (Computer-, Datenbankexperten) abhängig machen oder müsste selber einen solchen Experten für alle "Computerfragen" einstellen. Es ist doch z.B. klüger als kleines Ingineurbüro so viel wie möglich selber zu machen, oder?
Dann ist doch die Wahrscheinlichkeit wesentlich höher jegliche Probleme und Fehler selber zu lösen. Dass diese Datenbank dann natürlich nicht so perfekt ist wie die eines professionellen Informatiker´s ist doch klar.
Man kann doch nicht von jedem Firmengründer, der selbst noch so viele andere Dinge können und erledigen muss erwarten, dass er überall ein absoluter Experte ist!
Es gibt doch Foren, damit man Fragen stellen kann und gemeinsam darauf Antworten findet. Warum erwartest du dann so viel?

Hast du überhaupt schon mal ein Warenwirtschaftssystem aufgebaut?
Hab nämlich das Gefühl, dass du zwar MySQL und dergleichen kannst, aber wenig in die Praxis umsetzen kannst. Außerdem interpretierst du mir zu viel in die Dinge hinein, wie z.B. mit der Fixierung auf den Primärschlüssel.

Also ich denke, dass die Datenbank keine strukturellen Probleme hat, sich läuft doch ganz gut! Dafür bin ich ja da, dass diese Fehler eben behoben werden.

Ach ja und natülich ist sichergestellt, dass jede Firma nur einmal vorkommt und das jeder Ansprechpartner auch einer Firma zugeordnet werden kann, sonst wäre er ja kein ASP!! So was versteht sich von selbst und ich meine ganz blöd sind wir ja auch nicht.

Vielen Dank mwanaheri für deine Hilfe

Gruß jamesplate

sticky bit
16-11-2006, 20:42
Ordentlich normalisiert, wie kommst du auf die Idee, dass sie das nicht sei? Nur weil sie Handeingaben zulässt? Ist das immer gleich ein Fehler, wenn nicht alles automatisiert ist?
Ich denke nicht!!
Die Handeingaben haben mit der Normalisierung erst mal nichts zu tun... Nur wenn die Datenbank anständig normalisiert ist, dann lässt die nimmer jeden Schrott zu und dann wirds nervig für den User ständig wegen Tipfehlern o. Ä. Fehlermeldungen zu kassieren. Dient also mehr der Ergonomie...


Wenn jede kleine Firma eine komplett automatisierte Datenbank hätte, so würde sie sich doch von externen Informatikern (Computer-, Datenbankexperten) abhängig machen oder müsste selber einen solchen Experten für alle "Computerfragen" einstellen. Es ist doch z.B. klüger als kleines Ingineurbüro so viel wie möglich selber zu machen, oder?
Dann ist doch die Wahrscheinlichkeit wesentlich höher jegliche Probleme und Fehler selber zu lösen. Dass diese Datenbank dann natürlich nicht so perfekt ist wie die eines professionellen Informatiker´s ist doch klar.
Man kann doch nicht von jedem Firmengründer, der selbst noch so viele andere Dinge können und erledigen muss erwarten, dass er überall ein absoluter Experte ist!Also für 3. Normalform muss man kein "Datenbank-Experte" sein, sowas kann man wahrscheinlich sogar in nem VHS-Kurs lernen...
Für Ingeneure sollte ingeneurmässiges Arbeiten ja ohnehin kein Problem sein und ordentliches Datenbankdesign inkl. Normalisierung ist eben genau das, ingenieurmässiges Arbeiten...
Sonst haben die Damen und Herren Ingenieure mit der Datenbank nämlich bald Probleme die sie nimmer lösen können und auch kein anderer ("Experte" in was auch immer)...


Es gibt doch Foren, damit man Fragen stellen kann und gemeinsam darauf Antworten findet. Warum erwartest du dann so viel?Es gibt auch Leute die die Warnungen die sie in einem Forum bekommen auch ernst nehmen weil sie dadurch evtl. davor bewahrt werden (schlimme) Fehler zu machen...
Natürlich gibts auch die, die sich dadurch gleich angepisst und in ihrer Kompetenz beschnitten fühlen... ;)


Also ich denke, dass die Datenbank keine strukturellen Probleme hat, sich läuft doch ganz gut! Dafür bin ich ja da, dass diese Fehler eben behoben werden.Investiere mal 10 Minuten deiner Zeit, schmeiss ne Suchmaschine an um zu informieren was Normalisierung überhaupt bedeutet!


Ach ja und natülich ist sichergestellt, dass jede Firma nur einmal vorkommt und das jeder Ansprechpartner auch einer Firma zugeordnet werden kann, sonst wäre er ja kein ASP!! So was versteht sich von selbst und ich meine ganz blöd sind wir ja auch nicht.
Wie ist das sicher gesetllt, dass eine Firma nur einmal vorkommen kann? Constraint? Ich hoffe doch, sag jetzt nicht das macht der Client!
Und bitte was macht ihr wenn tatsächlich zwei Unternehmen gleicher Firma existieren (sowas kommt "in the Wild" nun mal vor)?
Aber die viel spannendere Frage, nehmen wir mal an, du legst ein neues Unternehmen an, mit der Frima "XYZ GmbH". Jetzt legst du ne Menge Ansprechpartner für dieses Unternehmen an. In der Datenbank sind die Ansprechpartner Firma über die Firma zugeordnet. Das besaget Unternehmen firmiert aber eines Tages um. Wird zur "XYZ AG", weil die so tolle Geschäfte machen und ihr Kapital aufstocken wollen. Und nu? Benennst du Firma einfach um. Entweder der Laden steht auf einmal ohne Ansprechpartner da, weil 'XYZ GmbH' <> 'XYZ AG'. Oder der Client muss sich bei diesem Update wieder darum kümmern, und das ist definitif das falsche Stück Software welches das tun sollte. Oder anderes Beispiel, was passiert wenn du ein Unternehmen löscht? Die Ansprechpartner bleiben halt leider im System hängen wenn der Client sich da wieder nicht drum kümmert. Bei Stammdaten, wie Kunden normalerweise darstellen, vielleicht nicht so schlimm aber bei Bewegungsdaten macht man sich so schnell nen schönen Datenmüllhaufen, das kommt dann immer besonders cool wenn man datenbankweite Auswertungen fahren möchte und lauter Phantomergebnisse bekommt und sich grün und blau wundert und auch ärgert...
Auflösung des Rätsel, die Verbindung zwischen Unternehmen und Ansprechparter wird hergestellt in dem der Primärschlüssel des Unternehmens als Fremdschlüssel beim Ansprechpartner gespeichert wird. Und die Firma des Unternehmens ist denkbar ungeeignet als Primärschlüssel...

Also jetzt im Ernst, deine Datenbank hat definitif ein Strukturproblem und zwar ein gewaltiges. Und wenn du willst, dass du bei dem Laden langfristig in guter Erinnerung bleibst um dort ggf. nach deinem Praktikum auch mal ne Anstellung zu bekommen, dann setzt dich hin lerne was über Datenbankdesign, zieh das Ding ordentlich from Scratch auf, vergiss den ganzen Scheiss wies vorher in Excel war (wenn es da immer noch drum geht) und gut ist. Jetzt ist der ideale Zeitpunkt. Wenn du jetzt ne Krücke aufsetzt (und du bist im Begriff das zu tun und das ist nicht als Angriff oder sowas gemeint!) dann werden die die so schnell nimmer los oder nur mit erheblichen Kosten, Aufwand und "Reibungsverlusten"!

Und bevor du mir jetzt auch unterstellst ich hätte gar keine Ahnung, nein mit Warenwirtschaftssystemen hab ich tatsächlich nichts am Hut aber mit ner datenbankgestützen CRM-Software, was das selbe in grün ist, muss ich mein täglich Brot erstreiten. Und leider sind in dem System zu Urzeiten genau solche Fehler gemacht worden wie du sie gerade im Begriff bist zu tun bist. Und das macht nur Ärger und beschert immer wieder die ein oder andere frustrierende Überstunde!

jamesplate
17-11-2006, 12:58
Und bevor du mir jetzt auch unterstellst ich hätte gar keine Ahnung, nein mit Warenwirtschaftssystemen hab ich tatsächlich nichts am Hut aber mit ner datenbankgestützen CRM-Software, was das selbe in grün ist, muss ich mein täglich Brot erstreiten. Und leider sind in dem System zu Urzeiten genau solche Fehler gemacht worden wie du sie gerade im Begriff bist zu tun bist.

:mad: Zunächst einmal lass ich mir nicht vorwerfen, igendwelchen Leuten in diesem Forum Unterstellungen gemach zu haben. War lediglich meine Meinung dazu, hab ich doch eindeutig geschriebe.
Eigenartig, dass du mir so etwas vorwirfst, vielleicht hat du nicht richtig gelesen? Lies doch einfach nochmal "sticky bit"


Hast du überhaupt schon mal ein Warenwirtschaftssystem aufgebaut?
Hab nämlich das Gefühl, dass du zwar MySQL und dergleichen kannst, aber wenig in die Praxis umsetzen kannst. Außerdem interpretierst du mir zu viel in die Dinge hinein, wie z.B. mit der Fixierung auf den Primärschlüssel.





Investiere mal 10 Minuten deiner Zeit, schmeiss ne Suchmaschine an um zu informieren was Normalisierung überhaupt bedeutet!


Auch weiss ich sehr wohl, was Normalisierung und im besonderen, was die dritte Normalform ist. Bevor du mir so etwas Unterstellst, in diesem Fall ist es eindeutig eine (Unterstellung), solltest du mal hinterfragen, wie du dieses Wort benuzten kannst ohne zu wissen, was es eigentlich bedeutet, denn nicht ich bin derjenige der anderen was unterstellt....


Auflösung des Rätsel, die Verbindung zwischen Unternehmen und Ansprechparter wird hergestellt in dem der Primärschlüssel des Unternehmens als Fremdschlüssel beim Ansprechpartner gespeichert wird. Und die Firma des Unternehmens ist denkbar ungeeignet als Primärschlüssel...


Das ist bereits der Fall Mr. Oberklug:rolleyes: .

Nachdem ich die Lösung für meine Frage hatte, habe ich natürlich den Primärschlüssel von der Tabelle Firma mit dem Fremdenschlüssel ADDR_ID in Tabelle ASP verknüpft. Nur war doch das Problem ein anderes, nämlich wie ich Feld ADDR_ID in ASP dengleichen Wert wie REC_ID zuweise, denn dieses Feld habe erst in die Datenbank eingebaut. Vorher war es über ein Feld Firma (hieß nicht so, aber egal) verbunden.
Anscheinend hast du die Problematik nicht ganz verstanden (kann sein das ich es schlecht erklärt habe).

Damit ist hoffentlich, deine Fragen, zur Sicherstellung von doppelten Firmen und Namensänderungen einr Firma.....beantwortet!
Wo ist jetzt ein strukturelles Problem?
Meine Frage war eine ganz andere, warum interpretiert ihr da so viel herein?

sticky bit
17-11-2006, 16:15
:mad: Zunächst einmal lass ich mir nicht vorwerfen, igendwelchen Leuten in diesem Forum Unterstellungen gemach zu haben. War lediglich meine Meinung dazu, hab ich doch eindeutig geschriebe.
Eigenartig, dass du mir so etwas vorwirfst, vielleicht hat du nicht richtig gelesen? Lies doch einfach nochmal "sticky bit"
Warum ist mein Nick in Anführungsstrichen, hat das was zu bedeuten?

Wie dem auch sei, einigen wir uns darauf, dass "unterstellen" von mir nicht wertend benutzt wurde, sondern ausdrücken sollte, dass du eine, deine ganz persönliche, Schätzung von mwanaheris Kenntnissen bzw. Fähigkeiten abgegeben hast. Wollte nur vermeiden, dass du, solltest du mich auch einzuschätzen versuchen, dich nicht verschätzt...


Auch weiss ich sehr wohl, was Normalisierung und im besonderen, was die dritte Normalform ist. Bevor du mir so etwas Unterstellst, in diesem Fall ist es eindeutig eine (Unterstellung), solltest du mal hinterfragen, wie du dieses Wort benuzten kannst ohne zu wissen, was es eigentlich bedeutet, denn nicht ich bin derjenige der anderen was unterstellt....
Gut, dann weisst du also was Normalisierung bedeutet. Stellt sich mir aber die Frage, wieso hast du dann die strukturellen Probleme deiner Datenbank nichts selbst erkannt, bzw. diese wenigstens gleich eingeräumt sondern in deiner Antwort irgenwas von automatisiert und "Experte" gefaselt?

Der geneigte Leser kann dir halt leider schlecht hinter die Stirn gucken und muss sich deshalb aus dem was du schreibst ein Bild machen. Und wen jmd. der auf auf Strukturprobleme seines Datenbankdesigns hingewiesen wurde das damit dementieren will, dass er anfängt zu erzählen dass Automatisierung nicht immer sein muss und man nicht für jede Aufgabe einen Experten braucht, dann ist davon auszugehen, dass dieser einen entweder zu veralbern versucht, gar nicht verstanden hat was ihm gesagt wurde und aus Reflex irgendwas ohne Zusammenhang erzählt oder an das was er schreibt tatsächlich glaubt und es einfach nicht besser weiss.

Aber steht dir ja frei mich aufzuklären was das zwingende und städige Benötigen eines Datenbankexperten mit dem Aufsetzen eines strukturell sauberen Datendesigns zu tun hat und wie da die Auswahlliste deiner Meinung nach noch reinspielt. Vielleicht gibts da ja tatsächlich Zusammenhänge die mir bisher nicht bewusst waren, klär mich bitte auf, ich will ja auch dazu lernen!


Das ist bereits der Fall Mr. Oberklug:rolleyes: .
Danke für das Kompliment! ;)
Aber unter uns, so oberklug bin ich gar nicht...


Nachdem ich die Lösung für meine Frage hatte, habe ich natürlich den Primärschlüssel von der Tabelle Firma mit dem Fremdenschlüssel ADDR_ID in Tabelle ASP verknüpft. Nur war doch das Problem ein anderes, nämlich wie ich Feld ADDR_ID in ASP dengleichen Wert wie REC_ID zuweise, denn dieses Feld habe erst in die Datenbank eingebaut. Vorher war es über ein Feld Firma (hieß nicht so, aber egal) verbunden.
Anscheinend hast du die Problematik nicht ganz verstanden (kann sein das ich es schlecht erklärt habe).

Wenn das Userfeld 01 von Tabelle ANSPRECHPARTNER (ASP) mit dem Firmennamen(Feld) aus Tabelle ADRESSEN übereinstimmt, dann soll die Addr_ID von ASP (is ja kein Primärschlüssel) den dazugehörigen Wert der ID aus Tabelle ADRESSEN erhalten.
Der Satz aus dem unteren Zitat liest sich für mich allerdings so, als wäre der Ansprechpartner über die Firma (asp.userfeld01) mit dem Unternehmen verbunden (adressen.firmenname).
OK, wenn ich jetzt von dir abgegebene Erläuterung dazu hinzuziehe und die Tatsache, dass ich den anderen Thread von dir kenn wo du erwähnst, dass das einem Excel-Werk kommt, kann ich auch rein interpretieren, dass die Spalte userfeld01 da nur temporär drin ist und du eben gerade mit deiner Updateaktion versuchst das Feld überflüssig zu machen. So ganz klar kam das aber für mich nicht raus, sah eher so aus, als soll userfeld01 und addr_id da beides drin existieren. Kann natürlich aber auch an mangelndem Textverständnis meinerseits liegen...


Damit ist hoffentlich, deine Fragen, zur Sicherstellung von doppelten Firmen und Namensänderungen einr Firma.....beantwortet!
Naja, ob du das mit der doppelten Firma nun tatsächlich über Constraint sicher stellst, wie es sein sollte weiss ich damit noch immer nicht und was du machst wenn der Laden tatsächlich mit zwei Unternehmen gleicher Firma eine Geschäftseziehung aufbaut weiss ich auch nicht, aber ich sag mal, das sind eher geringere Probleme...


Wo ist jetzt ein strukturelles Problem?
Wenn dieses Feld asp.userfeld01 rausfliegt und dafür asp.addr_id als Fremdschlüssel auf den addressen.id verweist, welches wiederum als Primärschlussel deklariert ist, dann sehe ich soweit es mir die Interpretation des von dir gezeigten Systemausschnitts zulässt, keines mehr.


Meine Frage war eine ganz andere, warum interpretiert ihr da so viel herein?
Da interpretiere ich jetzt rein, die Teilnehmer des Forums sollen sich bei gestellten Fragen keines Falls in die Problemsituation an sich reindenken um eine best mögliche Antwort zu geben die ggf. zwar von der eigentlichen Blickrichtung der Ursprungsfrage abweicht, das Problem aus dem die Frage heraus stellt aber prima lösen kann, bzw. dieses gar vermeiden hilft.
Und andererseits, kommt es auch immer darauf an wieviel Raum man mit seiner Frage für Interpretationen überhaupt offen lässt, ich sage nur 42... ;)