Hi,
erstmal eine Frage:
Zitat von
gsh:
Was ich bis jetzt mir überlegt habe:
Usertabelle:
(PrimärKey) UserID INT(10) Not Null Auto Inc
(PrimärKey) Username VARCHAR(100) Not Null
password VARCHAR(32) Not Null
email VARCHAR(100) Not Null
displayname VARCHAR(100)
Warum deklarierst Du hier einen zusammengesetzten Primary Key aus UserID und Username? Schon die ID identifiziert einen Benutzereindeutig, somit auch den Nutzernamen. Umgekehrt gilt das allerdings auch. Der Username muss schließlich im System eindeutig vergeben werden, entsprechend reicht dieser Name völlig aus um einen Nutzer eindeutig zu identifizieren. Wenn Du nicht auf ein O/R-Mapper setzt (oder ein anderes Tool/Framework/etc. einsetzt), welches eine künstliche ID bedingt, dann solltest Du die UserID einfach wegfallen lassen.
Zitat von
gsh:
So nun fangen meine Fragen an:
1) Welches Datenbanksystem verwende ich in diesem Fall am besten? MyISAM oder InnoDB?
Ich würde Dir zu InnoDB raten. Hier hast Du Transaktionen (quasi atomare Aktionen, werden ganz oder gar nicht ausgeführt) und referentielle Integrität. Damit hast Du zwei wichtige Vorteile eines
DBMS, welche Dir bei MyISAM einfach fehlen. Da die dafür sorgen können, dass Du immer ein konsistentes System vorfindest, sollte man nicht unnötig darauf verzichten.
Zitat von
gsh:
2) Ich möchte noch zusätzliche Informationen zu jedem User speichern (Adresse, EMail, Geschlecht, ...) ist es besser diese in die Usertabelle hinzuzufügen oder sollte ich eine eigene Tabelle mit alle zusätzlichen Informationen machen die dann über die UserID verknüpft ist?
Schau Dir mal Datenbanken - Normalisierungen an. Du solltest die dritte Normalisierung anstreben und dann einfach mal schauen, da sollte dann klar sein was besser ist (und wenn Du Dir die Erklärungen dazu anschaust sicher auch das Warum!)
Zitat von
gsh:
3) Wie kann ich die Kontaktliste am besten speichern? Ich habe mir überlegt eine Tabelle mit UserID und PartnerID. Aber angenommen ich habe 100.000 User jeder davon hat 10 Kontakte. Dann hätte diese Liste 1.000.000 Einträge. Ist das so denkbar oder gibt es eine viel bessere Lösung dafür?
Wo siehst Du denn dort das Problem? Die 1.000.000 Einträge? Dass ist doch gar nicht so viel. Geh einfach mal davon aus, dass das alles nur als zwei Referenzen gespeichert wird. Gehen wir mal von 64 bittigen Referenzen und 1.048.576 Einträgen aus, dann sind das gerade mal 8 MByte (8 Byte * 1.048.576). Die kannst Du entsprechend schnell verarbeiten. Natürlich kommt hier noch etwas Overhead für die Struktur hinzu, je nachdem wie Du das ganze abspeicherst um eben schneller über die Datensätze iterieren zu können oder eine schnelle Suche zu ermöglichen. Trotzdem sollte dies schon einen groben Eindruck geben, wie wenig das wäre.
An sich ist das übrigens durchaus eine Lösung, die völlig ok ist.
Du hast ggf. allerdings etwas Redundanz, die sich vermeiden lässt. Hier musst Du schauen, ob die Relation immer bidirektional ist, also gilt immer, dass wenn User A Partner B hat, dann auch User B Partner A hat? Wenn dem so ist, dann solltest Du nicht beide Richtungen abspeichern (macht die Pflege schwerer wenn die Partnerschaft aufgehoben wird, dann musst Du halt unnötig viele Stellen korrigieren). Da solltest Du dann lieber sicherstellen, dass es immer nur in einer Richtung gespeichert wird und dann eben beim Suchen entsprechend berücksichtigen (natürlich kann man aus Perfomance - Gründen auch eine unnötige Redundanz hinnehmen).
Wie Du hier vielleicht schon ahnst, es gibt keine Patentlösung. Vieles hängt vom konkreten Anwendungsszenario ab. Da können dann völlig unterschiedliche Ansätze für die Optimierung zum Einsatz kommen.
Gruß,
Der Unwissende