ユーザーがいくつかのモデル(記事、ブログ投稿など)の下書きを作成できるようにしたい。現在のモデル(articleDraft、blogpostDraftなど)ごとにドラフトモデルを作成して、これを実装することを考えています。これを行うためのより良い方法はありますか?ドラフトをサポートする必要がある既存のモデルごとに新しいモデルを作成するのは面倒で、大変な作業です。
5 に答える
レコードがドラフトであるかどうかを識別するために、テーブルにフラグ(例:draftと呼ばれるint列)を含める方が良いと思います。
私が見ることができるように、別のテーブルなしでそのような列を持つことの利点:
レコードをドラフトなしにするのは簡単です(フラグを変更するだけです)
データを複製しません(ドラフトレコードと非ドラフトレコードで実際に同じになるため)
コーディングは簡単で、複雑なログインはありません
すべてのデータが1つの場所にあるため、エラーの余地が少なくなります
私は、ActiveRecordデータのドラフト状態を作成するためのRubygemであるDraftsmanに取り組んできました。
Draftsmanのデフォルトのアプローチは、ポリモーフィックな関係を介して、ドラフトされたすべてのモデルのドラフトデータを単一のdrafts
テーブルに格納することです。オブジェクトの状態をJSONとしてobject
列に格納し、オプションで、列の変更を表すJSONデータを格納しobject_changes
ます。
article_drafts
Draftsmanを使用すると、必要に応じて、モデル(たとえば、 )ごとに個別のドラフトモデルを作成できますblog_post_drafts
。このアプローチはかなり面倒でエラーが発生しやすいことに同意します。
ドラフトデータを別々のモデルに分割する(またはsameera207の回答に従って、メインテーブルでブールフラグを使用する)ことの本当の利点は、大量のレコードを含む巨大なテーブルにdraft
なってしまうことがないことです。drafts
ただし、アプリケーションに大量の使用がある場合にのみ、これが実際の問題になることをお勧めします。
つまり、私の最終的な推奨事項は、すべてのドラフトデータをメインモデル(blog
)または単一のdrafts
テーブルに保存し、アプリケーションをスケールアップする必要がある場合は必要に応じて分離することです。
RubyToolboxのActiveRecordVersioningカテゴリを確認してください。現在のリーダーはPaperTrailです。
ステートマシンのルートをたどります。モデルが特定の状態にある場合にのみ、各属性を検証できます。複数のチェックボックスよりもはるかに簡単で、各状態の変更に1つまたは複数のアクションを関連付けることができます。
モデルにフラグがあると、いくつかの欠点があります。
データが有効でない限り、ドラフトとして保存することはできません。もちろん、Railsモデルでの検証はスキップできますが、データベースで定義されている「NOTNULL」列について考えてみてください。
「実際の」レコードを見つけるには、フィルターを使用する必要があります(「WHEREdraft = FALSE」など)。これにより、クエリのパフォーマンスが低下する可能性があります。
別の方法として、私の宝石の製図をチェックしてください。さまざまなモデルのドラフトを別のテーブルに保存します。