Normalisierung Freunde

[krisss11]

Hallo Leute,
Ich habe momentan gerade die totale Denkblockade! Bin dabei für ein Projekt die Tabellen auf Papier zu bringen!
Ich habe eine Tabelle für Benutzer und ich möchte gerne das diese Nutzer untereinander befreundet sein können. Leider fehlt mir gerade jeglicher Denkansatz um eine Beziehung zwischen den Nutzern darzustellen.
Es soll im Prinzip so aussehen,

User1 & User 2 sind Freunde

User2 & User 3 sind Freunde

User1 & User 3 kennen sich nicht

Wie stelle ich das in der Datenbank da? Ich brauch keine Befehle sondern nur die mögliche Darstellung.

Ihr habt doch sicherlich eine Idee oder?

Gesendet von meinem C6603 mit Tapatalk

[Observer]

Hi, da du hier ja nur einen Denkanstoß willst und dich sicherlich gut einarbeiten kannst heist das Zauberwort an dieser Stelle "Nested"
Da findest du auch mit Sicherheit einen Anhaltspunkt für die 2te Normalisierung die dir wie mir hier scheint noch fehlt.

MfG

[krisss11]

Hey, danke für deine Antwort!
Ich werde mich da mal schlau machen, aber auf dem ersten Blick scheint es nicht ganz das richtige zu sein?! Damit kann ich doch eher ne Hierarchie aufbauen, aber das möchte ich ja nicht! Oder sehe ich das falsch?
Ich meine die Normalisierung ist soweit fertig! Aber gut, dadurch das ich die freundschaftsbeziehung noch nicht drin habe natürlich nicht aber ohne das müsste es passen!

Die tabelle sieht so aus:
Tabelle Benutzer
B_id
Name
Vorname
Passwort
Email

Gesendet von meinem C6603 mit Tapatalk

[Lokutos]

Ich würde die Strucktur relative Simpel aufbauen
mit

USER-L | USER-R | FLAG
1 2 L
2 3 R


User Links und Rechts sind die Freunde

den Flag braucht du nur wen du z.b. sagst 1 mag 2, 2 ist 1 aber egal...

so kannst du z.b. L für Left oder B für Both sprich wen sich beide gegenseitig folgen

etc...

[Observer]

Hi, also ich habe mir für eine Buddyliste das Nested etwas vereinfacht gehabt.
Aber ok.
Kann dir ja mal den Ansatz nennen wie ich das dann machte.
Also Tabelle User :
user_id
name
usw.

Tabelle Buddy
user_id1
user_id2
status
datum_anfrage
datum_best
user_id_anfrage

Tabelle Buddy_Status

Also z.b.
1 = Anfrage
2 = Bestätigt
3 = Ignoriere
4 = Abgelehnt
usw

Das wäre die vereinfachte Form von meiner.
unter status habe ich eine Auflistung der Möglichkeiten die ich nutze.

Unter user_id1 habe ich immer die niedrigere id abgelegt.
datum_anfrage wann wurde diese Anfrage gestellt.
datum_best wann wurde diese Anfrage bestätigt und welchen Status ergab es dann.
user_id_anfrage wer von beiden hat diese Anfrage gestellt.

Habe dies so gemacht das ich Anfragen die z.b. nicht beantwortet werden nach einer gewissen zeit Löschen kann.
Der Rest bleibt dir überlassen wie weit du hiermit gehen willst.

Nested deswegen weil es ja schon eine Hierarchie hat.
Wie gesagt ist eine vereinfachte Form davon was ich da nutze bei mir, liegt daran das ich nicht ständig nach Datenleichen suchen möchte und vor allem daran das man hier dann auch mit Datum Arbeiten kann, z.B. dem User sagen wann wurde er angefragt und wie lange bleibt eine Anfrage erhalten ehe sie gelöscht wird.
usw. usw.

MfG

[krisss11]

Hi, danke für deine detaillierte Antwort ;-)
Also das Grundprinzip habe ich verstanden! Sehe ich das jetzt richtig, das die Tabelle Buddy aber keine direkt beziehung zur Tabelle User hat? Im Prinzip muss ich dann doch ne abfrage machen, ob eine buddy anfrage gestellt wurde, quasi ob Datensätze vorhanden sind und gegebenenfalls dann den Datensatz einfügen lassen oder?
Und wenn ich dann wissen möchte ob die user befreundet sind, muss ich ja nur nach einem Datensatz suchen mit den entsprechenden buddys und dem status "befreundet" ne?
Mit dem datum ist ne gute idee um die datenbank auch zu entlasten!

Gesendet von meinem C6603 mit Tapatalk

[Observer]

In deiner Abfrage machst du natürlich auch ein Join auf die Usertable.
Du brauchst ja den Namen des Users usw.
Ich dachte das wäre klar.
Deine Beziehung zur Usertabelle ist ja bei jedem eingefügten Datensatz doppelt vorhanden, da du ja die Freunde abfragst.
Ich mache das z.B. so das ich wenn sich Freundschaften auflösen diesen Datensatz wieder entferne.
Du kannst natürlich auch um eine History aufzubauen den Datensatz da lassen und ihn mit einem weiteren Flag versehen.
(So mache ich das ich hau die ehemaligen befreundeten in eine Historytable damit der User nachsehen kann ob dieser schon mal mit ihm befreundet war.)
Desweiteren habe ich aufgrund der Tatsache das ich Intern ein Benachrichtigungssystem habe auch einen Flag der sich Spam nennt, so kann ich im Admin sehen welcher User mehreren mit z.B. Werbemails auf den Keks geht und diesen dann entsprechend Einschränken oder bestrafen.

Das bleibt ganz deiner Fantasie so wie deiner Art Daten zu sammeln überlassen.

MfG

[krisss11]

Ja nee da habe ich mich falsch ausgedrückt, das ich join brauche ist klar!
Ich habe mich nur gewundert, weil man ja in der regel primary-keys vergibt! Fällt das bei den nested dann weg? Für die tabelle budy brauch ich ja eigentlich keinen, da ich eigentlich nur prüfe ob ein datensatz vorhanden ist bzw prüfe welcher vorhanden ist!
Oder irre ich mich mal wieder :-D?

Gesendet von meinem C6603 mit Tapatalk

[Observer]

Ne Irrst dich nicht.
Und ja normalerweise macht man da Primary oder baut Indizies auf aber hier sehe ich dafür keine Veranlassung.
Bei korrekt angewendetem Nested machst das aber trotzdem

MfG