2009-07-24 5 views
3

MySQLデータベースに冗長カラムを持たせることをお勧めします。私は自分のデータベースにUserテーブルを持っているが、個々の個々のユーザに関する多くの統計情報を表示できるようにしたいので、これが不思議です。これらの統計には、ユーザーが別のモデルとやり取りした回数やメッセージの数が含まれます。MySQLで複数のテーブルを使用する、またはRailsアプリケーションで複数のカラムを使用する

特定のオブジェクト(メッセージなど)のすべてのレコードを数え上げるためにパフォーマンスを低下させますか?あるいは、メッセージが追加/削除されるたびに更新されるtotal_messagesという冗長列をユーザテーブルに作成する方が良いでしょうか?ありがとう、これはしばらく私を混乱させています。

+0

一般何がでSQLクエリは遅くなりますか?それはSQLステートメントの複雑さですか?または、取得されたレコードの数?大量のレコードがあってもすべてが素早く見つかるでしょうか? – Anon

+0

私はすべてがより速く見つかるいくつかの状況があると思う、私はあなたが何を最長で取ることを見て最適化を試みる必要があると思う。たぶんクエリやページの読み込み時間を格納することはこれの良いスタートです。 –

答えて

3

短い答え:が経験則としても

を行い、Iはフライ(すなわちカウント)に基づいて計算することができるデータを作成し、更新する好きではありません。したがって、パフォーマンスのボトルネックを見つけてそれに応じて調整するまで、これらの重複した統計情報を追加することを延期します。

ユーザアクティビティに基づいて遡及統計を追加することができますので、絶対に必要な冗長性を追加するだけでアプリケーションを拡張することができます。

冗長データを追加するとパフォーマンスは向上しますが、すべてのソリューションに適合するサイズは決して1つではありません。その結果、使用量を計算して更新しようとすると、簡単なリクエスト。

2

私は、関連する情報を提供するviewをデータベースに作成します。冗長列を追加する代わりに、列のように外部世界に見える最適化可能なビットのSQLコードを追加しますが、これはデータと同期していることが保証されています。 SQLがビューを最適化するという事実は、データの検索を非常に高速にします。

0

Railsのcounter_cachesをチェックしてください。彼らはあなたのためにこれを行います。

http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html

これはmessages_countのユーザーテーブルの列を持っているあなたを必要とする(とmessages.countを使用してからあなたを救う)

class Messages < ActiveRecord::Base 
    belongs_to :user, :counter_cache => true 

    # ... 
end 

ような何か

関連する問題