電子メールを送信前に自動保存したり、ブログ投稿を終了または正式に保存する前に保存したりするアプリケーションにとって、最善の戦略は何ですか? 一時的なドラフト用にデータベース内の別のテーブルを使用するか、投稿をドラフトまたは公開済みとしてマークするステータス列を使用するのが最善でしょうか? 私はコードを探しているのではなく、メソッドだけを探していますが、保存する頻度など、他の関連するアドバイスも歓迎します.
2013 次
3 に答える
2
下書きと公開された記事の別々のテーブルは本質的に互いに重複することを考慮して、2 つを区別するためにステータス列を持つ 1 つのテーブルだけに傾倒します。
于 2009-03-27T20:21:33.340 に答える
2
私はウィキペディアのやり方でドラフトを作成します。最初のバージョンを保存し、すべての変更を (時間または明示的なユーザー コマンドに基づいて) 次のバージョンとして保存します。つまり。出版物の下書きグラフを削除できます-または削除できません。
データベースにデータを保存する場合は、同じテーブルを使用し (スキーマの競合を回避できます)、バージョン/ステータスを使用してドラフトのライフサイクルを追跡することをお勧めします。
于 2009-03-27T20:23:30.167 に答える
2
これはメール以外にも当てはまります...
私はこれで気が変わりました。最善の方法は、テーブルで is_draft 列を使用し、下書きと有効なエンティティの両方を同じテーブルに格納することです。これには、エンティティが下書き状態に切り替わっても同じ ID を保持できるという利点があります (保存後に編集したいが、必要な値を一時的に削除したい場合があります)。ユーザーが同じドキュメントで共同作業をしていて、id が変わり続けると、ユーザーが混乱する可能性があります。
is_draft=1 を使用して、ORM 検証ルールをオフにしたり、検証をトリガーしたり、制約をチェックして、無効なオブジェクトを保存できるようにします。はい、おそらくテーブルで null 許容フィールドを許可する必要があります。
プロセス: オブジェクトの保存を試みます。検証は失敗します。is_draft=1 を設定して、もう一度保存してみてください。それは保存します。画面のどこかに大きな「DRAFT」を入れてください:)
ユーザーが必要な情報を入力します。オブジェクトを保存しようとします。検証に合格します。is_draft=0 に設定します。それは保存します。
さて、電子メールとブログの投稿に関して、ユーザーが保存/投稿ボタンを押さない限り、サーバーはすぐに送信または投稿しようとすべきではありませんが、それは実際には別の問題です。
古い答え
問題は、ドラフトが有効でない可能性があり、実際のテーブルに保存できないことです。たとえば、テーブルで件名が null でないことを要求しているが、ユーザーがまだ入力していないとします。
1 つの方法は、ドラフト テーブルを用意し、エンティティ (およびその子) のシリアル化されたバージョンをそこに格納することです。php の serialize() を使用するか、json を使用できます。最終的に有効になると、システムは代わりに電子メール (またはその他の) テーブルに保存し、下書きを削除します。
疑似 SQL:
create table draft
id int primary key auto increment,
entity varchar(64) not null comment 'this way you can find all drafts of say type Email',
contents longblob not null,
modified timestamp comment 'this way you can sort by newer drafts'
modified_by int not null foreign key to user.id comment 'this way you can filter by the user\'s drafts'
下書きの添付ファイルまたは写真を保存するためのdraft_fileテーブルを検討し、それらに個別にアクセスできるようにすることもできます。
create table draft_file
id int primary key auto increment,
draft_id int not null foreign key to draft.id on delete cascade,
size int not null comment 'bytes',
mime_type varchar(64) not null,
file_name varchar(255) not null,
contents longblob,
thumbnail blob comment 'this could be an icon for files/documents'
そのため、ユーザーはメールの作成を開始し、おそらく本文を入力して添付ファイルを追加します。GUI はメールを下書きに保存し、添付ファイルをアップロードして、draft_file に保存し、下書き ID と、GUI に表示するファイルのダウンロード URL を返します。
件名を入力します (To は空白のままです)。GUI はメールを下書きに保存し、前のステップで ID を認識しているため、下書きテーブルを ID で更新します。
ユーザーが [宛先] フィールドに入力し、[送信] をクリックします。サーバーは電子メールを電子メール テーブルに保存し、添付ファイルを draft_file から email_attachment テーブルにコピーし、できればトランザクション内で下書きを削除します。
これにより、実際のエンティティ テーブルの整合性を維持しながら、長期間の下書き、gmail スタイルの添付ファイルのアップロードが可能になります。
于 2012-02-09T05:23:47.180 に答える