Eine effiziente Datenbank-design für ein einfaches forum mit php und mysql

Ich bin in den Prozess der Gestaltung einer Datenbank für forum-Funktionen für meine website.Nach einer Suche, SO google, habe ich folgende Konstruktion:
User-Tabelle

Username : varchar(256)
Password : varchar(256)

Threads Tabelle

ThreadId  :  int
UserId    :  int, related to Users table
Title     :  varchar(255)
Date      :  timestamp, when a thread was created

Beiträge Tabelle

PostId   :   int
ThreadId :   int, related to Threads table
UserId   :   int, related to Users table
Date     :   timestamp, when post was made
Title    :   varchar(255) - post title (optional)
Body     :   text - the actual body of a post

Obwohl dies dient meinem Zweck, ich kann nicht helfen, aber denke, das ist nicht sehr effizient, vor allem für die Auswahl der Beiträge zu einem bestimmten thread, für die es notwendig sein würde, durchqueren Sie die gesamte Tabelle.

Aus der Spitze von meinem Kopf, ich kann denken von einem design, wo die Benutzer-Tabelle und Threads Tabelle bleiben, wie Sie sind, aber statt eine einzige Tabelle für die Beiträge Tabelle,erstelle ich ein Beiträge Tabelle für jeden Benutzer mit dem gleichen Namen wie der Benutzer.Auf diese Weise abrufen, alle Beiträge zugehörig zu einem thread ist viel effizienter,da alles was ich brauche ist die userid der person, die begonnen haben, den thread.Mit diesem info-ich Suche die Tabelle mit dem gleichen Namen, um alle Beiträge für den spezifischen thread.Aber es ist eine gute Idee, um die Anzahl der Tabellen, die ich erstelle direkt abhängig von der Anzahl der registrierten Benutzer?Was ich auch wissen möchte ist, welche der beiden designs besser skaliert,wird einfacher zu verwalten? Gibt es eine bessere Datenbank-design für meine Anforderung?

Check out: net.tutsplus.com/tutorials/php/..., obwohl offensichtlich verwenden Sie PDO oder mysqli statt

InformationsquelleAutor just_a_coder | 2013-11-16

10

Ihrem Entwurf sieht im wesentlichen richtig.

Dies ist ein klassisches "normalisiert" Daten-Struktur - genau die Art von Form, dass relationale Datenbanken sind dafür gebaut. Wenn Sie nicht wissen, über die normalen Formen, aber kam mit dieser Struktur, dann ist Sie klar haben ein natürliches Verständnis von, wie relationale Datenbanken funktionieren.

http://en.wikipedia.org/wiki/Database_normalization#Normal_forms

Damit PHP zu vermeiden, durchqueren Sie die gesamte Tabelle, die Sie sollten sicherstellen, dass Sie Ausgabe einer SQL-Anweisung, wählt nur die Datensätze, die Sie suchen. E. g.
```
SELECT * FROM posts WHERE ThreadId = ? ORDER BY Date
```
Ihre Sorge um die Datenbank zu müssen, Durchlaufen Sie die gesamte Tabelle ist fair und angemessen, aber Sie können dies vermeiden, - dies ist eine klassische relationale Datenbank-problem, das gelöst wurde, wenn Sie zuerst erschienen als kommerzielle Produkte, die vor mehr als 30 Jahren.

Können Sie einen INDEX erstellen, auf Beiträge unterstützt die SQL ausgeführt werden. In diesem Fall etwas entlang der Linien von:
```
CREATE INDEX postThreadsIndex ON posts ( ThreadId, Date )
```
Dieser index ermöglicht es, Ihre Datenbank-engine, um finden der Datensätze, die Sie, Sie wählen sehr schnell, ohne Lesen Sie die gesamte Tabelle. Wenn Sie wissen wollen wie, Lesen Sie auf b-Baum-Indizes.

http://en.wikipedia.org/wiki/B-tree

Wie ich bereits sagte in der Antwort, dies ist genau die Art von Sache, die relationalen Datenbanken wurden gebaut, und Ihr design ist solide und angemessen.

Nicht zu prüfen, alle alternativen - du hast es gleich beim ersten mal!

Aber, für die Vollendung Willen - lassen Sie uns betrachten Sie die von Ihnen vorgeschlagenen alternative.

Dir empfehlen die Aufteilung der Post-Tabelle von User - dies würde Folgendes bedeuten:
- Benutzer "UserA" einen thread erstellt - seine erste Eintrag ist gespeichert in posts_UserA
- Benutzer "UserB" antwortet der post - seine post ist stockwerkartig in posts_UserB
- Benutzer "BenutzerC" antwortet der post - Ihre post ist stockwerkartig in posts_UserC
Um die volle Faden, den Sie jetzt brauchen, um sich in posts_UserA, posts_UserB und posts_UserC.

Wenn dies waren nur drei Benutzer, dann würden Sie brauchen, um sich durch alle Daten, die in diesen drei Tabellen, um alle zu finden die Beiträge, und das wäre gleich der Anzahl der Datensätze, die würde wurden in der Tabelle Beiträge in Ihrer ursprünglichen design.

Gewinnen Sie nichts.

Wenn Sie hatte 1000 andere Nutzer wären, müssten Sie auch einen Blick in diese anderen 1000 Tabellen, um zu finden, dass Sie nicht alle Datensätze.

Sie noch nichts gewinnen.

Könnte man hinzufügen, eine weitere Tabelle zu speichern, die Nutzer kommentierten auf die Beiträge - und somit die Tabellen zu schauen, aber jetzt ist die Lösung beginnt zu kompliziert.

Du könnte split die Tabelle Post von Thread - das würde bedeuten, dass alle posts, wo in einer Tabelle basierend auf dem thread, dass Sie gemacht wurden, auf. Das würde wohl auch ziemlich gut sein für die Auswahl der Beiträge in einem einzigen thread, aber es wäre schrecklich für:
- Auswahl aller Beiträge von einem bestimmten Benutzer.
- Suche nach den letzten post, unabhängig von thread.
- findet alle Beiträge, die an einem bestimmten Datum.
- etwas anderes, das nicht mit einem bestimmten Thema.

Grundsätzlich die alternative, die Sie vorschlagen kann effizienter für einen ganz bestimmten Abfrage, aber es wird fast immer sehr kompliziert für jede andere Abfrage.

Das original-design ist einfacher für alle Fragen und führen Sie auch durch das hinzufügen von Indizes.

Wenn Sie jemals an den Punkt gelangen, wo Sie Ihre SQL-performance zu langsam ist, weil das Volumen der Daten, dann kannst du schauen Tabellenpartitionierung, die tut, was Sie beschreiben, in einer unsichtbaren Weise. Aber um ehrlich zu sein, Sie sind unwahrscheinlich, dass jemals benötigen, es sei denn, Ihre Website ist sehr beliebt - und wenn das der Fall ist, dann werden Sie wahrscheinlich haben Sie das Geld zu investieren in ein Grundlagen von relationalen Datenbanken natürlich an diesem Punkt sowieso...
- sogar, wenn ich Tat, erstellen Sie Indizes für die Beiträge,threadid wäre es immer noch inefficent(intern) als php-server müssen durch die gesamte Tabelle abrufen von Datensätzen für ein besonderes threadid, also ich kam mit dem zweiten design.was sind Ihre Gedanken auf die zweite Datenbank-design, nicht die ersten?
- Nein, PHP sollte nicht müssen Durchlaufen der gesamten Tabelle wählen Sie die Datensätze, die Sie möchten, die mit SQL. E. g. SELECT * FROM posts WHERE threadId = ?
- sorry, sql müssen durch die gesamte Tabelle rechts finden Sie alle Einträge mit einem bestimmten threadid.Wie denken die folgenden intern arbeitet?Durch das Durchlaufen der gesamten Tabelle rechts? Obwohl SELECT * FROM posts WHERE threadId = ? würde tun, was ich will,aber es wäre langsamer als die zweite Datenbank-design-Recht?
- Nein, es wäre nicht, wenn Sie einen index zur Unterstützung der Auswahl, die Sie wollen. Die Fragen, die Sie Fragen grundlegend sind, wie relationale Datenbanken funktionieren und die Probleme waren gelöst viele, viele Jahre her. Ich werde zu aktualisieren meinem beantworten, um klarer zu werden...
- Ich aktualisiert meine Antwort deutlich - ich hoffe, das deckt den Großteil deiner Fragen.
InformationsquelleAutor Rob Baillie

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.