это относится не только к электронной почте ...
Я передумал об этом. Лучший способ - использовать столбец is_draft в вашей таблице и хранить как черновики, так и допустимые объекты в одной таблице. Преимущество заключается в том, что объект сохраняет тот же идентификатор, даже если он переключается в состояние черновика и выходит из него (вы можете отредактировать его после сохранения, но временно удалить необходимое значение). пользователям было бы непонятно, если бы они работали над одним и тем же документом, а идентификатор менялся, amirite?
вы бы использовали is_draft = 1, чтобы отключить правила проверки ORM, вызвать проверки или проверить ограничения, чтобы разрешить сохранение недопустимого объекта. да, вам, вероятно, придется разрешить пустые поля в вашей таблице.
процесс:
попытаться сохранить объект. проверка не пройдена. установите is_draft = 1 и попробуйте сохранить снова. это экономит. поместите большой "ПРОЕКТ" где-нибудь на экране:)
пользователь заполняет необходимую информацию. попытаться сохранить объект. проверка проходит. установить is_draft = 0. это экономит.
Теперь, что касается электронной почты и сообщений в блоге, ваш сервер не должен пытаться отправить его или опубликовать его сразу, если пользователь не нажмет кнопку «Сохранить / отправить», но на самом деле это другая проблема.
СТАРЫЙ ОТВЕТ
Проблема в том, что черновик может быть недействительным и не может быть сохранен в фактической таблице. Например, скажем, ваша таблица требует, чтобы тема не была нулевой, но пользователь еще не заполнил ее.
Один из способов - создать черновую таблицу и сохранить в ней сериализованную версию сущности (и ее дочерних элементов). php's 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'
Вы также можете рассмотреть таблицу черновиков для хранения вложений или фотографий для черновика и получить к ним доступ по отдельности:
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, сохраняя при этом целостность таблицы реальных сущностей.