私はAttackReportとAttackReportRoundのような2つのモデルを持っています。各レポートは多くのラウンドを持つことができます。それは攻撃の仕方を記述します。これは私が最初にやりたかったことをどのようにしてデザインしたかです。しかし、例えば30ラウンドの攻撃がある場合、AttackReportRoundテーブルはすぐに大きくなりすぎる可能性があります。Railsのシリアル化。それはここでうまく適用されますか？
したがって、可能な限り、または最も効率的な方法で1行に格納する方法を考えていました。攻撃ラウンドでは、攻撃側のヒット、ダメージ、防御側のヘルスなどの情報が保持されます。
私は、単一のattackReportエントリで各ラウンドのデータをシリアル化することを考えていました。おそらく、カンマ区切りの値またはある種のレール直列化を使用していました。
この場合、あなたはどうしますか？
データベーステーブルは、特にインデックスを適切に使用している場合、パフォーマンスが悪くなる前に多くの行を保持できます。他のテーブルの古いAttackReportエントリとAttackReportRoundエントリを「アーカイブする」と考えましたか？これは、1年前のAttackReportが頻繁にクエリされないことを前提としています。あなたのアプリが何をしているかによってまったく異なります。
シリアライズを行う場合は、独自のCSVソリューションを実行する前に、ビルトインのRailsを使用します（yamlにシリアル化し、コーディングはほとんど必要ありません）。
JSONにシリアル化して1行に格納できます。あなたのデータベースは小さくなるかもしれませんが、ある程度の柔軟性とパフォーマンスを失うでしょう。
また、Mongoのようなドキュメント指向のデータベースを試すこともできます。 AttackReportは文書であり、AttackReportRoundsはレコードまたはサブ文書であるため、うまくいくかもしれません。
Mongoのようなものを使用したくないので、おそらくJSONをチェックする必要があります。ありがとう！ – Spyros
私はこのテーブルが本当に速く成長すると思っています。 1日あたり1000回の攻撃が少なすぎると想像してみましょう.30,000回の試合のようなものかもしれません。長期的には悪いようですが、データベースは大量でもうまくいくと私は同意します。私はインデックスについても考えてきましたが、テーブル内にあまりにも多くのエントリーがあるという考えはまだ不快です。たぶん、シリアル化は道のりですが、レールは完全なモデルのシリアル化しかサポートしていないと思いますが（私の場合は値が私によって定義されています）、それをチェックする必要があります。 – Spyros
十分に公正。たぶんシリアル化が最善の方法です。 Railsにモデルの特定の属性のみを直列化するように伝えることができるかどうかはわかりませんが、そうでなければハッシュの配列を直列化することを検討できます（各ハッシュはラウンドを表します）。 –