MySQL n-m beziehung erstellen.

[JasonX]

Hallo,

ich habe eine Frage zur realisierung hiervon.

Wenn ich eine n-m Beziehung zwischen 2 Tabellen aubauen will, muss ich ja mit einer Hilfstabelle arbeiten.

Kann ich in der Hilfstabelle eindeutige IDs verwenden oder wäre das in diesem Fall eher sinnlos ?

Hier gehts darum, das ich einem Kunden mehrere Programme zuordnen will,
die jeweiligen Programme können aber von mehreren Kunden verwendet werden.

Das ganze soll dann natürlich am Ende über PHP abgefragt werden, wobei ich die Datenverknüpfung mit SQL realisieren würde -sprich JOIN- Funktion verwenden würde.

Ziel soll es sein, das wenn ich Updates für ein Programm haben sollte ich dies hinterlege und mir dann durch die Abfrage jeder Kunde angezeigt wird, der diese Software einsetzt und ein Update benötigt.

Denk ich hier vllt sogar zu komplex ?

MfG
Jason

[Gast]

Hallo,

ich habe eine Frage zur realisierung hiervon.

Wenn ich eine n-m Beziehung zwischen 2 Tabellen aubauen will, muss ich ja mit einer Hilfstabelle arbeiten.

Kann ich in der Hilfstabelle eindeutige IDs verwenden oder wäre das in diesem Fall eher sinnlos ?

Hier gehts darum, das ich einem Kunden mehrere Programme zuordnen will,
die jeweiligen Programme können aber von mehreren Kunden verwendet werden.

Das ganze soll dann natürlich am Ende über PHP abgefragt werden, wobei ich die Datenverknüpfung mit SQL realisieren würde -sprich JOIN- Funktion verwenden würde.

Ziel soll es sein, das wenn ich Updates für ein Programm haben sollte ich dies hinterlege und mir dann durch die Abfrage jeder Kunde angezeigt wird, der diese Software einsetzt und ein Update benötigt.

Denk ich hier vllt sogar zu komplex ?

MfG
Jason
ne das ist eine frage der referentiellen integrität. wenn du in der hilfstabelle eindeutige ids verwendest, kannst du die einträge nachher nicht mehr so ohne weiteres löschen z.b. durch eine löschweitergabe. letztenendes hängt es aber davon ab, wie du das machen willst. für eine einfache n-m beziehung ist das von dir beschriebene szeario jedoch ausreichend. du musst eben nur aufpassen, wie du dann neue datensätze anlegst und wie du die löscht. auf die beziehung an und für sich hat das aber keinen einfluss, mit dem unterschied, dass man z.b. bei einem zusammengesetzten primärschlüssel (der besteht aus einer kombination zweier ids in der hilfstabelle) nur ein schlüsselpaar haben kann, logischerweise. wahrscheinlich ist es am besten wenn du das machst und dann damit rumprobierst, dann merkst du wo ggf. probleme auftreten.

[Matrix316]

In MSSQL nehmen wir immer eine Spalte mit einem "Unique Identifier", aber eine eindeutige ID kann man im Prinzip auch nehmen. Dann kann man auch einem Kunden mehrfach das gleiche Programm zuweisen (wenns unterschiedliche Versionen sind z.B.)

[Marscel]

Billig und effektiv:

* Primärschlüssel: standardmäßige, fortlaufende Nummer
* Index: über n_id und m_id und "unique" setzen

Solange es nämlich keinen verdammt guten Grund gibt, stattdessen irgendwelche wilden Primärschlüsseltupel aufzusetzen, und in etlichen Jahren ist mir bisher keiner untergekommen, macht es das Handling sehr viel bequemer, den Datensätz primär einfach mit einer einzigen Spalte ansprechen zu können.

[RattuS]

Man spricht bei diesem Dilemma von einem Surrogate Key (http://de.wikipedia.org/wiki/Surrogatschl%C3%BCssel). Rein technisch ist es leichter mit diesem künstlichen Schlüssel zu arbeiten. Theoretisch ist es aber unsauber, weil überflüssig. Identitäten beschreiben Entitäten. Eine Relation ist keine Entität im Sinne des RDBS, daher gehört dazu kein Schlüssel.

Am Ende des Tages ist das aber keine Frage, die man nicht tot analysieren sollte. Entwickler schwören auf IDs, DB-Administratoren auf die Reinheit ihrer DB. Such dir was aus. ;)

[Gast]

Eine ungeschriebene Regel im Datenbankdesign lautet, die Beziehungen immer so lose wie notwendig aufzubauen, bzw. so lose wie möglich (ohne Einschränkungen jeglicher Art, nur da wo es unbedingt notwendig ist). So bleibt man bei späteren Änderungen (die aber möglichst nicht eintreten sollten) oder alternativen Anwendungen flexibel. Zumindest sollte diese Regel für den Hausgebrauch ausreichend sein.