Question

在发送电子邮件之前自动保存电子邮件或在完成或正式保存之前保存博客文章的应用程序的最佳策略是什么？是否最好在数据库中使用单独的表格进行临时草稿，或者将状态列标记为草稿或发布？我不是在寻找代码，只是方法，但任何其他相关的建议都会受到欢迎，比如保存的频率等等。

Answer 1

考虑到草稿和已发表文章的单独表格基本上是彼此重复的，我会倾向于只有一个带状态列的表来区分这两者。

Answer 2

我按维基百科方式起草：保存第一个版本，并保存所有修改（基于时间或显式用户命令）作为下一个版本。之后ie。您可以删除草稿图表 - 或者不删除。

如果您将数据保存在数据库中，我认为使用同一个表（可以避免架构冲突），并使用版本/状态来跟踪草稿生命周期。

Answer 3

这不仅适用于电子邮件......

我改变了主意。最好的方法是在表中使用is_draft列，并将草稿和有效实体存储在同一个表中。这样做的好处是实体保持相同的ID，即使它进入和退出草稿状态（您可能希望在保存后编辑它，但暂时删除所需的值）。对于用户来说，如果他们在同一个文档上进行合作并且ID不断变化，那将会让人感到困惑，amirite？

您将使用is_draft = 1来关闭ORM验证规则，触发验证或检查约束以允许无效对象保存。是的，您可能必须在表中允许可以为空的字段。

过程：尝试保存对象。验证失败。设置is_draft = 1并尝试再次保存。它节省了。把大“DRAFT”放在屏幕上某处：）

用户填写所需信息。尝试保存对象。验证通过。设置is_draft = 0。它节省了。

现在，关于电子邮件和博客帖子，您的服务器不应该尝试发送或立即发布，除非用户点击保存/发布按钮，但这确实是一个不同的问题。

老答案

问题是草稿可能无效，无法保存在实际表格中。例如，假设您的表要求主题不为null，但用户尚未填充它。

一种方法是拥有草稿表，并将实体（及其子代）的序列化版本存储到其中。 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样式的附件上传，同时保持真实实体表的完整性。

自动保存草稿的最佳做法？

3 个答案: