-2

コンテキストを提供するために、Pusher(Websocket Service over cloud) を使用してリアルタイム チャット アプリケーションに取り組んでいます。ここでは、各メッセージがサーバーに記録されてから、Websocket サーバーにプッシュされ、データがクライアントにプッシュされます。メッセージの保存に MySQL を使用しています。

そのようなテーブルの 1 つが私のメッセージで、次のフィールドがありますid,chat_payload,message_time,user_id,room_id

最初のチャットルームにデータを入力するには、メッセージ履歴を取得する必要があります。各メッセージ オブジェクトには が含まれます。username,useravatar,chat_payload,timestampただし、テーブルuseravatar,usernameはそれぞれテーブルに格納されます。したがって、テーブルが非常に急速users, user_metaに拡大するため、結合を使用して実行時にデータを取得すると、明らかにコストがかかるように見えます。ユーザー名、ユーザーアバターをテーブルに保存することは、更新の問題を引き起こすため、正しくないようです。user_metamessages

上記のシナリオを考慮して、適切なDB /アプリケーション設計を提案してください。

4

1 に答える 1

1

メッセージテーブルにユーザー名、ユーザーアバターを保存しています...更新の問題が発生します

良いデータが一番の仕事ですよね?あなたは、確信できないパフォーマンスの約束のためにそれを妥協することを考えています.

通常の形式は、いわゆる更新異常を防止するために特別に考案されたものであると過小評価されることがあります。3NF は、データの一貫性を維持するために大いに役立ちます。追加の利点として、更新する必要がある情報の量が最小限に抑えられるため 、冗長性の欠如は効率的です。

これらの理由から、他の 1000 の理由の中で、最良の行動は、教科書が言うように、正規化されたデータベースを設計し、チップをどこにでも落とすことです。お使いの DBMS は、結合を念頭に置いて設計されています。そして、それらを効率的にするための多くの機能、特にインデックスを備えています。何が速いか遅いかについての最初の印象ではなく、それを信頼してください。

パフォーマンスの問題が発生した場合でも、データベースの設計自体に問題があるとは考えられません。もしそうなら、それはゆっくりと起こり、実際の状況に基づいて実際の事実に基づいてそれを調べて修正する時間があります. あるほうが、ないよりはましです。

于 2016-07-15T06:05:16.473 に答える