Datenbank Denormalisierung?

Question

Um etwas Kontext zu schaffen, arbeite ich an einer Echtzeit-Chat-Anwendung mit Pusher (Websocket Service über Cloud), wo jede Nachricht in meinem Server angemeldet ist, bevor es auf den Websocket-Server geschoben wird, der die Daten an den Client schiebt .So verwende ich ein MySQL zum Speichern der Nachrichten.

Also eine solche Tabelle ist meine Nachrichten, die die folgenden Felder id,chat_payload,message_time,user_id,room_id hat.

Für die anfängliche Chatroom bevöl ich müsste die Nachricht Geschichte abzurufen, wobei jedes Objekt Nachricht die username,useravatar,chat_payload,timestamp .Aber der useravatar,username umfassen würde, wird in users, user_meta Tabellen gespeichert respectively.So die Daten auf der Flucht zu holen scheint mit Joins deutlich teuer, da user_meta Tabelle wächst sehr fast .Und klar Speichern Benutzernamen, useravatar in messages Tabelle scheint nicht richtig, da es würde Probleme mit der Aktualisierung.

Also unter Berücksichtigung des oben genannten Szenarios könnte jemand bitte eine entsprechende DB/Application Design für die gleichen vorschlagen?

Answer 1

Speichern von Benutzernamen, useravatar in Tabelle Nachrichten ... würde updation Probleme aufwerfen

Gute Daten Job # 1, nicht wahr? Sie denken darüber nach, Kompromisse einzugehen, denn das Leistungsversprechen ist nicht sicher.

Es ist manchmal unterschätzt, dass normale Formen speziell entwickelt wurden, um das zu verhindern, was Updateanomalien genannt wird. 3NF wird viel dazu beitragen, Ihre Daten konsistent zu halten. Als zusätzlichen Vorteil ist der Mangel an Redundanz effizient, weil es die Menge der Informationen minimiert, die aktualisiert werden müssen.

Aus diesen Gründen, unter 1000 anderen, ist die beste Vorgehensweise, eine normalisierte Datenbank zu entwerfen, wie die Lehrbücher sagen, und die Chips fallen lassen, wo sie können. Ihr DBMS war entworfen mit Joins im Hinterkopf, können Sie sicher sein. Und es hat viele Funktionen, um sie effizient zu machen, nicht zuletzt Indizes. Verlassen Sie sich darauf und nicht auf Ihren ersten Eindruck von dem, was schnell oder langsam sein könnte. Wenn Sie Leistungsprobleme haben, ist es unwahrscheinlich, dass das Datenbankdesign per se fehlerhaft ist Wenn dies der Fall ist, wird es langsam geschehen, und Sie werden Zeit haben, es zu untersuchen und es auf der Grundlage einer tatsächlichen Situation mit echten Fakten zu korrigieren. Besser als damals, als jetzt ohne.