Лучшие практики автосохранения черновиков?

Учитывая, что отдельные таблицы для черновиков и опубликованных статей будут дублировать друг друга, я бы склонялся к одной таблице со столбцом статуса, чтобы различать их.

Я делаю черчение по методу Википедии: я сохраняю первую версию, а все модификации сохраняются (в зависимости от времени или явной команды пользователя) в качестве следующей версии. После т.е. публикации можно удалить черновик-график - или нет.

Если вы сохраняете данные в базе данных, я думаю, что хорошо использовать одну и ту же таблицу (вы можете избежать конфликтов схемы) и использовать версию/статус для отслеживания жизненного цикла черновиков.

это относится не только к электронной почте...

Я передумал на этот счет. Лучший способ — использовать столбец is_draft в вашей таблице и хранить как черновики, так и действительные объекты в одной таблице. это имеет то преимущество, что объект сохраняет один и тот же идентификатор, даже если он переключается в состояние черновика и выходит из него (вы можете захотеть отредактировать его после сохранения, но временно удалите требуемое значение). это могло бы сбить пользователей с толку, если бы они совместно работали над одним и тем же документом, а идентификатор постоянно менялся, amirite?

вы должны использовать is_draft=1, чтобы отключить правила проверки ORM, активировать проверки или проверить ограничения, чтобы разрешить сохранение недопустимого объекта. да, вам, вероятно, придется разрешить пустые поля в вашей таблице.

процесс: попытаться сохранить объект. проверка не проходит. установите is_draft=1 и повторите попытку сохранения. это спасает. поставить где-нибудь на экране большой "ЧЕРНОВИК" :)

пользователь заполняет необходимую информацию. попробуйте сохранить объект. проверка проходит. установить is_draft=0. это спасает.

теперь, что касается сообщений электронной почты и блогов, ваш сервер не должен пытаться отправить или опубликовать их сразу, если пользователь не нажмет кнопку «Сохранить/опубликовать», но на самом деле это другая проблема.

СТАРЫЙ ОТВЕТ

Проблема в том, что черновик может быть недействительным и не может быть сохранен в реальной таблице. Например, скажем, ваша таблица требует, чтобы тема не была нулевой, но пользователь еще не заполнил ее.

Одним из способов было бы иметь черновую таблицу и хранить в ней сериализованную версию сущности (и ее дочерних элементов). 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' 

Итак, пользователь начинает составлять электронное письмо, возможно, просто набирает текст и добавляет вложения. ваш графический интерфейс сохраняет электронное письмо в черновики и загружает вложения, сохраняет их в файле draft_file и возвращает идентификатор черновика и URL-адреса загрузки для файлов, которые вы отображаете в своем графическом интерфейсе.

он вводит Тему (Кому по-прежнему пусто). Ваш графический интерфейс сохраняет электронное письмо в черновики, обновляя таблицу черновиков по идентификатору, поскольку он знает свой идентификатор из предыдущего шага.

ваши пользователи заполняют поле «Кому» и нажимают «Отправить». Ваш сервер сохраняет электронное письмо в таблице электронной почты, копирует вложения из файла draft_file в таблицу email_attachment и удаляет черновик, желательно в рамках транзакции.

это позволяет создавать долгосрочные черновики, загружать вложения в стиле Gmail, сохраняя при этом целостность вашей реальной таблицы сущностей.