Datenbankdesign und Abfrage

[magu]

Hallo,
da ich kompletter Newbie bin, was Datenbankdesign angeht bitte ich um Hilfe bei der (vermutlich) relativ einfachen Problemstellung.

Ich möchte eine Datenbank entwickeln, in der Immobilien verwaltet werden. Es gibt einerseits die registrierten user (Primärschlüssel ist der "username") und andererseits eine Reihe von Immobilien (Primärschlüssel wäre eine interne ID). Folglich wird die Datenbank eine Tabelle "tbl_user" mit (username, adresse, telefon, etc...), sowie eine Tabelle "tbl_immobilien" mit (immo_id, Art, Größe, Kaufpreis, etc...) beinhalten.
Es ist jetzt so, dass zwischen Nutzern und Immobilien eine m:n Relation bestehen soll. Ein Nutzer kann demnach mehrere Immobilien einsehen, wobei ein und die selbe Immobilie gleichzeitig von mehreren Nutzern abgefragt werden kann. Frage: Wie geht das?

Meine Idee war (was ich auch denke in Google gefunden zu haben), eine zusätzliche Tabelle mit Zugriffsrechten einzuführen. Diese besteht aus zwei Spalten, nämlich die Zuordnung "username" und "immo_id", also z.B:
user_A immo_id 1
user_B immo_id 1
user_C immo_id 1
user_A immo_id 2
user_C immo_id 3
user_C immo_id 1

Ist dies der "normale" Weg, eine derartige Problemstellung zu lösen? Wenn ja, wie würde eine SQL-Abfrage aussehen, bei der eine Liste der Immobilien ausgegeben wird, die allerdings nur user_C zugeordnet sind?

[Falk Prüfer]

Hallo,

um es von Anfang an richtig zu machen, solltest du auch für die Nutzertabelle eine "interne ID" als Primärschlüssel verwenden, also einen technischen PK und KEINE Nutzdaten.
Um jetzt deine m:n Beziehung abbilden zu können beötigst du - wie du bereits herausgefunden hast - eine zusätzliche Tabelle für die Abbildung der Beziehungen. Auch diese Tabelle sollte sinnvollerweise einen Primärschlüssel bekommen. (Da die DS in deinem Bsp. nicht eindeutig sind, könntest du sonst nie einen davon gezielt löschen!)
Zu deiner Abfrage: Wie ist das "nur user_C zugeordnet" zu verstehen. Nur im Sinne von auschließlich user_c, also in deinem Beispiel immo_id 3 oder nur die Immobilien von user_c, also immo_id 1, immo_id 3 und immo_id 1? Sind sie Doppelungen gewünscht oder nur ein Fehler in den Beispieldaten?
Um nur die Immobilien abzufragen die user_c zugeordnet sind, genügt ein Join über die drei Tabellen:
[highlight=sql]
select i.* from tbl_immobilien i
inner join tbl_user_immo um on um.immo_id = i.immo_id
inner join tbl_user u on u.user_id = um.user_id
where u.username = 'user_c'
[/highlight]
Das andere "Nur" wird etwas komplizierter

Gruß Falk

[magu]

Hallo,

tnx für die Tipps. Die Tabelle der Beziehungen hätte meiner Meinung nach einen zusammengesetzten Primärschlüssel, nämlich aus username und immo_id - das sollte doch genügen, oder. Dann könnte ich die Einträge aus der Tabelle auch jeweils löschen, wenn entweder ein User aus dem System entfernt wird, oder auch wenn eine Immobilie verkauft wurde. Und mehr, denke ich, brauche ich in dieser Tabelle nicht.
Die Doppelung war tatsächlich ein Fehler in den Beispieldaten, dies ist natürlich nicht gewünscht!
Und mit der Interpretation meines Ausgabewunsches liegst Du auch richtig - ich brauche sämtliche Immobilien, die einem Nutzer zugeordnet sind, unabhängig davon, ob diese auch anderen Nutzern zugeordnet sind.

Gruss, magu

[Falk Prüfer]

...Die Tabelle der Beziehungen hätte meiner Meinung nach einen zusammengesetzten Primärschlüssel, nämlich aus username und immo_id - das sollte doch genügen, oder. Dann könnte ich die Einträge aus der Tabelle auch jeweils löschen, wenn entweder ein User aus dem System entfernt wird, oder auch wenn eine Immobilie verkauft wurde. Und mehr, denke ich, brauche ich in dieser Tabelle nicht....

Man könnte hier die beiden Felder als Primärschlüssel verwenden. Ich gebe aber zu bedenken, daß es immer bestimmte Nachteile mit sich bringt, a) einen zusammengesetzten PK und b) Nutzdaten als PK zu verwenden. OK, wenn die beiden Felder FKs zu technischen PKs sind, dann fällt b) weg, da es keine "echten" Nutzdaten sind. Aber a) steht immer noch im Raum und auch wenn du momentan denkst nicht mehr zu brauchen ... Anforderungen können sich ändern!

Gruß Falk