Zitat von
Der_Unwissende:
Hi,
Hi und erstmal vielen Dank für deine ausführliche Antwort
Zitat von
Der_Unwissende:
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.
Die UserID und den Usernamen hab ich aus folgendem Grund: Die UserID ist die eindeutige ID für diesen User. Bei einer anderen Tabelle (z.b. Avatar) wird diese ID dann verwendet, um den jeweiligen Eintrag einem User zuordnen zu können. Den Usernamen will ich dafür nicht verwenden, da es 1. ein Name ist (Feld muss größer sein) und 2. vielleicht einmal von dem User oder von mir geändert werden kann.
Noch kurz warum ich zwei Primär Keys hab:
Ich denke, ein select sollte man immer nur auf einen identizierten Eintrag durchführen. Da sich der User über den Usernamen anmeldet, brauch ich den am Anfang und dann verwendet der Server nur noch die UserID zur Identifikation.
Zitat von
Der_Unwissende:
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.
hmm ok hat InnoDB sonst irgendwelche Nachteile?
Funktionieren die Zeos überhaupt richtig mit den Transaktionen?
Zitat von
Der_Unwissende:
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!)
ok danke schau ich mir an
Zitat von
Der_Unwissende:
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
Ich war mir nicht ganz sicher, ob das überhaupt ein guter Lösungsansatz ist.
Ich glaub schon, dass ich für jeden Kontakt einen Eintrag benötige, da, nur weil Person A Kontakt B hat, noch lang nicht Person B die Person A als Kontakt haben muss.
Zitat von
Der_Unwissende:
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
jaja das ist doch immer so
