rodger

Tagchen,

ich versuche grade ein buddy-system für meine Webseite zu schreiben. Nun frage ich mich, soll ich eine neue Tabelle anlegen, oder mit der bestehenden user-tabelle arbeiten, in der username, uid, adresse etc abgespeichert werden.

Ich dachte mir dabei, man könnte doch das Feld auslesen und im Falle einer einladung die neue uid mit einem drangehängten "," an den bestehenden String anhängen. dann könnte man bei Bedarf das Feld auslesen, um zu sehen, ob der string zb "25," im feld enthalten ist. so könnte man sich die zusätzliche tabelle sparen und wohl auch einige SELECT-Abfragen.
Haltet ihr das für eine gute Vorgehensweise oder eher nicht? mich würde auch interessieren, wie resourcenintensiv so eine stringüberprüfung dann wäre.

Vielen Dank für eure antworten, Rodger

Mister Ad

Steve

Moin rodger,

es ist grundsätzlich falsch, in einem Feld CSV-Werte zu speichern, das schreit förmlich nach (Stichwort) Normalisierung.

Du hast eine 1:n-Beziehung (ein Benutzer kann beliebig viele Buddys haben), also mein Vorschlag, eine zusätzliche Tabelle:
Id, UserId, BuddyUserId

Und mach dich in dem Zusammenhang auch über Einführung in Joins schlau, du benötigst nämlich keine zusätzlichen Abfragen.

BlackScorp

also normalerweise hat man für sowas 2 tabellen. user und buddys mit folgenden spalten:

user

id | username | ....

buddys

id | userid | buddyid | allow(oder etwas in der art) | ....

also wer hat wen als freund und hat der user den anderen als freund akteptiert oder nicht

MFG

__________________
Mein kleines Projekt
-Cruel Online-
5 von 3 Leuten können kein Bruchrechnen

rodger

Hi,

ich nehme mal an CSV steht für comma separated value?! und normalisierung bedeutet in diesem Zusammenhang was?
EDIT: ok, lese grad in dem link, da steht ja was über die Normalisierung, alles klar.
Das mit den Joins werd ich mir jetzt mal anschauen.

rodger

@Blackscorp

ja, das hab ich nun schon öfter gesehen. da wird dann für jeden Vorgang einer einladung ein neuer Datensatz angelegt oder?
Also ich finde die Idee mit der einen Tabelle ja nach wie vor reizvoll, wenn ihr aber alle sagt, das so eine komma-getrenntes Auslesen usw nicht do der Hit ist, dann lass ich mich da auch gern eines besseren belehren.

Steve

Für uid, adresse und etc. hast du ja sicherlich auch separate Felder, nach deinem Ansatz könntest du die ja auch komma-separiert (ja, das heißt CSV) in ein Feld stopfen

Ansonsten kannst du bezüglich Normalisierung erstmal hier einsteigen:
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

rodger

mir fällt gerade noch etwas ein. und zwar arbeite ich mit TYPO3, die felder aus der Tabelle mit den userdaten werden sowieso als globale variablen gespeichert, der zugriff ist also etwas einfacher. auch deshalb fönde ich es praktisch, die daten in der fe_users tabelle zu speichern. was meint ihr?

@steve, es ist etwas anderes meinst du nicht? uid, adresse und sagen wir username sind eine feste anzahl von spalten, und zwar 3, bei der buddylist weiß man ja nicht genau, wieviele freunde der user haben wird.

BlackScorp

naja mal angenommen ich habe 20 buddys in meiner liste. Nun habe ich mich mit einem gestritten und sage buddy nr 12 löschen. der ganze Prozess würde ungefair programmiertechnisch so aussehen:

du liest meine uid aus. spaltest alle werte mit einem komma, entfernst die nr 12, setzt wieder alles zusammen und speicherst wieder alles ab.

und so würde es aussehen wenn du 2 tabellen hast:

die userid haste bestimmt sowieso irgendwo gespeichert wegen login, und die id des zu löschenden users steht ja in der url. also brauchste nur delete from buddys WHERE user = id and buddy = id und schon habe ich ein freund weniger. es ist nicht nur einfacher sondern auch noch ressourcen sparender

__________________
Mein kleines Projekt
-Cruel Online-
5 von 3 Leuten können kein Bruchrechnen

rodger

@blackscorp
das klingt wirklich nachvollziehbar. werde das nun wohl auch so machen. frage mich halt jetzt nur noch, wie da die Sache mit dem Join zu paßt? andere Frage wäre noch, ist es nun wirklcih so, das für jeden add as buddy vorgang eine neue zeile angelegt wird? ich denke mal ja. das hieße dann wohl, das sich dort rasch sehr viele Zeilen ansammeln könnten, aber das ist dann wohl egal, nehm ich mal an.

Steve

Ja, ok, der Vergleich war unpassend, aber es ist wie gesagt eine 1:n-Beziehung und diese lagert man gewöhnlich in eine separate DB-Tabelle aus.
Du kannst natürlich auch Arrays in Feldern speichern, aber früher oder später schießt du die damit ins Knie, glaub mir

Wenn ich mich jetzt in dich hineinversetzen soll (aus eigener Erfahrung), würde ich meinen, du hast eine Abneigung gegen JOINs (maximal hast du bisher ein Implizites genutzt) und bevorzugst desshalb deine Ansicht.