2016-06-20 11 views
1

テーブルのすべてが同じフィールドと属性を持つ場合、1つのモデルを異なるテーブルに使用する方法はありますか?私は3百万のレコードを持つ最初のテーブルを持っています。私は将来、高速クエリを行うために 'tablename_2'のような別のテーブルを作ることを考えています。レールで1つのモデルを使用して複数のテーブルを管理することは可能ですか?

私は既存のモデルを使用したいと思いますが、いくつかの条件に基づいて、どのテーブルにアクセスする必要があるかを決定する必要があります。

これが可能かどうか知りたいですか?

+0

かなり奇妙な要件。 1つのテーブルを持つ方が良いでしょうか?とにかく、あなたは同一構造のテーブルをたくさん持っています。 – retgoat

+0

非常に奇妙なアーキテクチャ。あなたはより具体的で、いくつかの例を挙げることができますか? – Kkulikovskis

+0

複数のテーブルを表すカスタムモデルを作成するのではなく、別のモデルを使用して異なるテーブルに保存するために、コントローラとヘルパーを使用する方がよいでしょう。私の経験では、ActiveRecordはこのような状況を非常にうまく処理しません。 – Smar

答えて

3

あなたはこのような何か試してみたいことがあります。

class Example < ActiveRecord::Base 
    def self.within_table(name) 
    begin 
     previous_table_name = self.table_name 
     self.table_name = name if name.present? 
     yield if block_given? 

    ensure 
     self.table_name = previous_table_name 
    end 
    end 

    # ... 
end 

そして、これでそれを呼び出す:

# This register will be created in 'examples' table (default table name) 
Example.create! attribute: 'value' 

# Las element from 'examples' table 
Example.last 

Example.within_table 'examples_copy' do 
    # This one will be created in 'examples_copy' table 
    Example.create! attribute: 'value' 
    # Last register of 'examples_copy' table 
    Example.last 
end 

してください、このコードはおそらく安全スレッドされていないことを念頭に置いてクマをし、注意深く使用する必要があります。また、異なるテーブル間でモデルコンテンツを分割することはお勧めしません。別のモデル(single table inheritange)を使用する必要があります。

3

はい。 水平データベーススケーリングまたはスケーリングを出力します。これにより、大きなデータベースは負荷を処理するために小さなセットに分割されます。 垂直スケーリングまたはスケーリングupは、ハードウェアを増やすことによって行われます。

1.リード

これらは通常、高い読み取り/書き込み比でアプリを使用している

をレプリカ:

スケールアウトの2つのオプションがあります。若干の作家によって書かれた記事が世界の何百万人も消費されるニュースサイトを考えてみましょう。基本的には、すべての書き込みを処理する1つのマスターデータベースがあり、その後、読み取り操作を処理するスレーブデータベースに複製されます。

2.データベースシャーディング

データベースの行によって、テーブルによって、機能することにより、地理学によって、クライアントによって、または任意の他の尺度のいずれかによって分割することができます。データベース間でデータは共有されません。データの間に明確な境界がある、つまり異なる国のSaas顧客を持っていて、別の国のデータが必要になる可能性がない場合は、このアーキテクチャを使用します。

もっと読むここhttps://www.wikiwand.com/en/Shard_(database_architecture)

この質問は、しかし、Railsのよりも、データベースのアーキテクチャで行うことが多くを持っています。私があなたの靴の中にいた場合、スケールを外すことを検討する前に、非正規化、インデックス作成、クエリの最適化、および垂直スケーリングに焦点を当てます。

3百万のレコードはpostgreSQLでは問題にならないはずですが、月に100%増えている場合は、データベースへのスケーラビリティをベーキングするのが賢明でしょう。

関連する問題