Dark Guardian

Es kommt auf die Verwendung der Daten an.

Z.b. wenn du wie hier im Forum die Kontaktmöglichkeiten unter jedem Beitrag anzeigen lassen willst, wäre es sinnvoll diese Daten (da sie häufig ausgelesen werden) von anderen zu trennen um eine "kleine" performantere Tabelle zu haben.

Wenn das nicht der Fall ist, kann das auch getrost mit in die Tabelle wo email, wohnort etc. drin steht.

Mister Ad

Screeny

Ahhhh! =D

D.h. Daten die bsplw. bei jedem Profilbesuch aufgerufen werden in gesplittete Tabellen geschrieben. So muss in der DB keine Tabelle mit 10 Spalten und 4000 Einträgen durchsucht werden. Demnach ist es besser diese Informationen in eine Performance Tabelle zu schreiben die z.B nur 5 Spalten hat.

Ist eigentlich logisch.

Vielen Dank für die interessanten und vorallem nützlichen Informationen!

Hat noch jemand einen Tipp den er mir mit auf den Weg geben kann bevor ich die DB designe?

lieben Gruß!

mepeisen

Aus Normalisierungssicht ist eine Kreuztabelle für den dargestellten Fall schlichtweg völlig überflüssig. Sebst wenn du Attribute in einer Zeile einzeln speicherst ist es weiterhin vollkommen überflüssig.

Bevor du also sagst, ich würde hier Scheiße erzählen, lern erst einmal was über Datenbank-Design und Normalisierung.

User-Tabelle: Primärschlüssel User-ID
Attribut-Tabelle Variante 1: Primärschlüssel und Foreign-Key User-ID, Haufenweise Spalten für die Attribute
Attribut-Tabelle Variante 2: Primärschlüssel Attribut-ID, Foreign-Key User-ID, Char Attribut-Name, Char Attribut-Value, Unique key User-ID+Attribut-Name

Wo hast du da Platz (und sinnvolle Verwendung) für eine Kreuztabelle? Kreuztabellen bilden in der Regel n:m Beziehungen ab und hier gibt es keine. Bestenfalls kann man ein einzelnes Attribut, wie beispielsweise den Wohnort als n:m Beziehung verstehen. Wobei es aber eine zusätzliche Tabelle "Ort" gäbe und die Tabelle "Attribut" als Kreuztabelle verstanden werden kann.


Bzgl. der Performance: Ausprobieren. So pauschal gibt es da keine Antwort. In jedem Fall solltest du dir einige Grundregeln dabei beherzigen und das bedeutet: VarChar-Felder und Blob/Textfelder drücken die Performance vor allem, weil das DB-System da bzgl. der Datensatzlängen u.U. jonglieren muss.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Flor1an

Wenn du für 4000 Einträge planst, sogar wenn du unter 50 000 bleibst, würde ich alle Informationen in einer Tabelle speichern. Damit hast du weniger Aufwand beim programmieren (brauchst keine JOINs, musst nicht zwei Tabellen updaten etc.).

Über die Performance solltest du dir noch keine Gedanken machen. Erst wenn dein System wirklich Probleme bekommt kannst du überlegen die Tabellen aufzusplitten. Wenn du alle DB Abfragen in Models auslagerst (MVC) dann kannst du auch sehr leicht deine Tabellenstruktur aufsplitten ohne viele Änderungen am eigentlichen Code machen zu müssen.

Ich selbst betreibe ein System mit rund 200 000 Usereinträgen mit rund 40 Spalten. Probleme mit der Performance treten bei der Usertabelle aber nicht auf, da kommen ganz andere Fehlerquellen viel eher.

Also mach dir darum erstmal nicht so einen großen Kopf, programmiere lieber dein System sauber, dann kannst du später an der Performance drehen (falls es überhaupt nötig wird, bei kleinen Hobbyprojekten eher selten der Fall!)