SQL Datenbank Struktur Facebook Freunde speichern

[tender89]

Servus Leute,

Also ich bau grad eine Android App welche einen Facebook Login benutzt.

So der Login funktioniert einwandfrei und der Benutzer wird in die Datenbank eingetragen.
Nun habe ich aber eine Frage an euch.

Falls sich jemand jetzt über den Facebook Login einloggt werden auch seine Freunde abgerufen.
So nun müssen diese Freunde auch in die Datenbank.

Aber wie mach ich das?

Sagen wir ich logge mich ein und bekomme einen Array mit 30 Freunden zurück welche zu mir gehören.
Dieser Array gestaltet sich auf Facebook ID, Bild-Url und Name.

Diese Daten werden in der Freundesliste gebraucht welche aufgelistet werden kann. (also in der app)

Wie pack ich diese Freunde in meine Mysql Tabelle ein?

Muss ich dann für jeden Benutzer eine eigene "Freunde-Tabelle" erstellen ?
Wenn dann zb 1000 Leute sich über den Facebook Login eingeloggt hätten würde das 1000 Tabellen machen.

Oder muss ich einfach eine weitere Spalte mit Freunden hinzufügen und dort die ID´s eintragen?

Bin bisl verwirrt und hoffe jemand kann mir helfen.

 

[evilbaschdi]

"So" schon mal an Datenschutz gedacht? Muss man wirklich überall seine Facebookfreunde mit ins Boot holen müssen, wenn man sich für ne App registriert??? Evtl. wollen die ja garnicht, dass ihre Daten in deiner App gespeichert werden!

Ungeachtet dessen: Du brauchst nicht für jeden Freund ne eigene Tabelle sondern nen eigenen Datensatz in der Tabelle. Sprich, du du iterierst durch das Array und schreibst für jeden Eintrag nen neuen Eintrag in diese "Freunde Tabelle" undter Zuordnung dieser Freunde zum eigentlichen Benutzer, damit der am Schluss wirklich auch nur seine Freunde sieht.

FreundeTabelle:
FacebookId (von Freund), BildUrl, Name, FacebookId (vom User)

Das der technische Ansatz für nen Prozess, den ich noch immer sche*** finde.

 

[tender89]

Also Pack ich ALLE Freunde von jedermann in eine "Gesamt Freunde Tabelle" und Speicher die Id's der Freunde
an den Dazugehörigen Benutzer??

Da ist ja Datenschutz = Nada... Falls der Server/Datenbank gehackt wird oder so... alles in einer Tabelle..

Geht das echt nicht anders?!

Falls die App dann zb 1.000.000x runtergeladen wird ,wird die Freunde Tabelle min 500.000 Einträge haben.

Ist das einer Datenbank anzutrauen die NUR auf einem Server läuft??

Server hat 6Core 12Gb SSD und 100 mbit.

 

[evilbaschdi]

wenn der server, bzw. die datenbank gehackt wird, ists eh egal, wo was steht. wer was von sql steht, kommt auch da dahinter.

bei kritischen daten empfiehlt sich natürlich immer, die daten entsprechend zu verschlüsseln, sodass die facebook ids bzw. die namen nicht im klartext in der datenbank stehen.
für jeden user ne eigene table ist jedenfalls quatsch. frage ist eh, ob du die daten überhaupt speichern musst oder nicht einfach nur während der verarbeitung temporär hältst und nach dem logout wieder verwirfst. dazu fehlt mir allerdings der hintergrund, was deine app überhaupt tun soll.

Ergänzung (30. Juli 2014)

lädst du die datenbank auch zum user in die app?? dann musst du die datensätze natürlich auf die ihn gültigen einträge beschränken. die komplette datenbank würde zu viel traffic verursachen.
wenn du nur text speicherst, sollten die 12 gb eigentlich schon ausreichen.

 

[tender89]

Also viel kann ich leider nicht verraten.

Benutzer sammeln Punkte durch lösen von Sachen.
Facebook Nutzer können von ihren Freuden Extra Punkte anfordern wie zb bei "Candy-Crush" Tickets anfordern.
Es wird ein Internes Facebook-Freunde-Ranking System geben . Also eine Tabelle wer halt mehr Punkte hat.

Und dazu muss halt eine Freunde-Tabelle erstellt werden.
Diese werden druch ihre Facebook ID welche zuerst verschlüsselt wird Identifiziert.

edit:

Die Facebook-Freundeliste wird auf dem Handy abgespeichert und wird nur vom
Benutzer selber Aktualisiert.

 

[evilbaschdi]

musst ja dann nicht alle freunde speichern sondern nur die, die schon spielen *grübel*

 

[tender89]

musst ja dann nicht alle freunde speichern sondern nur die, die schon spielen *grübel*

Man bekommt auch nicht alle Freunde von Facebook. Sondern nur die welche auch den Facebook Login in der App benutzt haben.
Datenschutz von FAcebook. Das die sowas haben xD

edit :

was spricht dagegen für jeden facebooknutzer eine eigene freunde-tabelle zu erstellen?

 

[Pr3c4rio]

dann wird deine komplette tabellen-struktur unübersichtlich und du wirst nen problem mit den abfragen bekommen.
wenn du 100000user hast hättest du ja auch 100000tabellen.

i.d.R implementiert man so freundesverwaltungen als struktur, mit einer tabelle die die ganzen zuordnungen enthält.
wenn du willst modellier ich dir das auch als erm zur veranschauung. ^^

die tabelle hat dann halt mit wachsender mitgliederzahl auch ne wachsende anzahl an einträgen, was aber völlig egal ist

 

[tender89]

hey Pr3c4rio danke für die Antwort.

Aber ich hab noch eine Frage. Wenn die Freunde-Tabelle mal echt 1.000.000 erreichen sollte,
geht dann nicht viel Performance verloren? Wenn dann zb 100 Leute Gleichzeitig versuchen ihre Freunde-Liste zu
aktualisieren bedeutet deren ihre Aktuelle Punktzahlen abrufen wollen,
führt das nicht zu einer extremen Long-Querry?

Oder rattert der Server das unter 100ms raus? Vorausgesetzt die Ganze Tabelle ist im Ram.

Wie viel mb kann theoretisch so eine Tabelle haben wenn diese 1.000.000 Einträge hätte .

 

[Pr3c4rio]

naja die abfragen an sich laufen auch dann noch ohne bemerkbare verzögerungen ab.
ab wann genau dein system an seine grenzen stößt wird sich dann ja zeigen.

die implementierung ist auf jeden fall die effizienteste und bietet die meisten vorteile.

die tabelle enthält dabei aber nur die zuordnungen also userid und freundid. dabei für jeden freund nen eigenen datensatz(stichwort normalisierung).

 

[DanielBm]

hey Pr3c4rio danke für die Antwort.

Aber ich hab noch eine Frage. Wenn die Freunde-Tabelle mal echt 1.000.000 erreichen sollte,
geht dann nicht viel Performance verloren? Wenn dann zb 100 Leute Gleichzeitig versuchen ihre Freunde-Liste zu
aktualisieren bedeutet deren ihre Aktuelle Punktzahlen abrufen wollen,
führt das nicht zu einer extremen Long-Querry?

Oder rattert der Server das unter 100ms raus? Vorausgesetzt die Ganze Tabelle ist im Ram.

Das kommt immer auf den Anwendungsfall an.
Vorausgesetzt du hast geeignete Indizes erstellt, sollte so ein einfacher Query kein Problem sein.
Dafür muss auch nicht die ganze Tabelle im RAM sein, da du ja sowieso einen Filter angibst.

Evtl. würde es Sinn für dich machen, dich mal ein bisschen in Datenbanktheorie einzuarbeiten, damit du die Strukturen und Mechanismen verstehst.
Zu mysql gibt er vermutlich mehr als genug Material im Internet.

 

[Freezedevil]

Wie viel mb kann theoretisch so eine Tabelle haben wenn diese 1.000.000 Einträge hätte .

Das kommt natürlich auf deine Datensätze an.
FB-ID: 4 Byte
Bildurl: 100 Byte
Name: 50 Byte

+ Freundetabelle (8 Byte pro Freund)

< 300 Byte pro Nutzer

Wären dann Bei 1 Mio. Nutzern 300MB was für ein DBMS wohl ein Witz anstatt ein Problem ist.

Du brauchst genau zwei Tabellen: Nutzer(FBID, Bildurl, Name), Freunde(FBID, FBID)
In der Freundetabelle speicherst du natürlich jede Beziehung nur einmal. Die Freundschaft zwischen 1 und 2 ist die selbe wie zwischen 2 und 1.

 

[tender89]

Das kommt natürlich auf deine Datensätze an.
FB-ID: 4 Byte
Bildurl: 100 Byte
Name: 50 Byte

+ Freundetabelle (8 Byte pro Freund)

< 300 Byte pro Nutzer

Wären dann Bei 1 Mio. Nutzern 300MB was für ein DBMS wohl ein Witz anstatt ein Problem ist.

Du brauchst genau zwei Tabellen: Nutzer(FBID, Bildurl, Name), Freunde(FBID, FBID)
In der Freundetabelle speicherst du natürlich jede Beziehung nur einmal. Die Freundschaft zwischen 1 und 2 ist die selbe wie zwischen 2 und 1.

Ich danke euch. Hab mal wieder viel zu kompliziert gedacht.

 

[tender89]

Das kommt immer auf den Anwendungsfall an.
Vorausgesetzt du hast geeignete Indizes erstellt, sollte so ein einfacher Query kein Problem sein.
Dafür muss auch nicht die ganze Tabelle im RAM sein, da du ja sowieso einen Filter angibst.

Evtl. würde es Sinn für dich machen, dich mal ein bisschen in Datenbanktheorie einzuarbeiten, damit du die Strukturen und Mechanismen verstehst.
Zu mysql gibt er vermutlich mehr als genug Material im Internet.

Hey Servus Danke für deine Antwort. So vermeide ich dann doppelte unnötige Einträge. Sehr geil .
muss ich der Freundetabelle einen Index geben? also (ID FBID FBID)

Ich verstehe nur nicht ganz wie das gehen soll.

ist es dann so FREUNDELISTE (ID / FACEBOOK_ID_1 / FACEBOOK_ID_2) ??

 

[Pr3c4rio]

nur die 2fb ids.

 

[Daaron]

Kreuztabellen benötigen gar keine separate ID-Spalte. Der Primärschlüssel ist zusammengesetzt aus den beiden Fremd-IDs, die verknüpft werden. Jeder Eintrag der n:m - Relation ist per Definition einzigartig.

 

[tender89]

nur die 2fb ids.

okey also ich habe eine tabelle Freunde(friend1 / friend2 )

wenn ich jetzt zb von user ID = 1 alle freunde haben möchte müsste ich ja beide Spalten überprüfen.

2/1
1/8
9/1

so hier zb wäre ja dann user id 1 in beiden spalten verfügbar.
muss ich dann mit UNION arbeiten?

1.
SELECT friend2 as userid FROM tabelle where friend1 = 1
SELECT friend1 as userid FROM tabelle where friend2 = 1

2.
SELECT friend2 as userid FROM tabelle where friend1 = 1 
UNION 
SELECT friend1 as userid FROM tabelle where friend2 = 1

so jetzt hätte ich von user id 1 alle freunde id's in einer sql. soweit richtig?

 

[Hancock]

Wie wärs mit or?

select * from Tabelle where friend1=1 or friend2=1

Musst halt die richtigen Indizes setzen (auf friend1+friend2 und auf friend2+friend1 z.B.).

 

[tender89]

Wie wärs mit or?

select * from Tabelle where friend1=1 or friend2=1

Musst halt die richtigen Indizes setzen (auf friend1+friend2 und auf friend2+friend1 z.B.).

mhmm mit (select * from Tabelle where friend1=1 or friend2=1) wähle ich aber alles in der spalte aus.
Mit der UNION variante wäre doch alles schon schon sortiert.
welche variante ist den effizienter?

die auswahl packe ich dann sammt in ein ARRAY.
das ARRAY brauch ich dann um zu überpfüfen ob neue freunde in meinem vergleichs array sind,
falls ja werden diese dann in die freunde tabelle eingetragen.

 

[Kanibal]

Wenn das was größeres wird, ist womöglich ein NoSQL-Ansatz empfehlenswert - so werden auch die Daten bei Facebook gespeichert. Vertreter sind Redis, MongoDB und mehr.

Die Resourcen, sich da einzuarbeiten, sollten ja bei einem "Geheimprojekt" mit "1.000.000x Downloads" verfügbar sein