esto se aplica a más de correos electrónicos ...
he cambiado de opinión en este caso. La mejor manera es usar una columna is_draft en su tabla y almacenar tanto borradores como entidades válidas en la misma tabla. esto tiene la ventaja de que la entidad conserva la misma ID, incluso si entra y sale del estado de borrador (es posible que desee editarla después de guardarla, pero elimine temporalmente el valor requerido). Sería confuso para los usuarios si estuvieran colaborando en el mismo documento y el ID siguiera cambiando, amirite?
usaría is_draft = 1 para desactivar las reglas de validación de ORM, activar validaciones o verificar restricciones para permitir la guarda de un objeto no válido. sí, es probable que deba permitir campos con nulos en su tabla.
proceso: intente guardar el objeto. la validación falla establecer is_draft = 1 e intentar guardar de nuevo. ahorra. poner un gran "DRAFT" en la pantalla en algún lugar :)
el usuario completa la información requerida. intenta guardar el objeto pases de validación establecer is_draft = 0. ahorra.
ahora, con respecto a las publicaciones de correo electrónico y blog, su servidor no debería intentar enviarlo o publicarlo de inmediato a menos que el usuario presione el botón Guardar/Publicar, pero eso es realmente un problema diferente.
vieja respuesta
El problema es que un proyecto podría no ser válida, y no puede ser guardado en la tabla real. Por ejemplo, supongamos que su tabla exige que el tema no sea nulo, pero el usuario aún no lo ha completado.
Una forma sería tener una tabla de borrador y almacenar una versión serializada de la entidad (y sus elementos secundarios) en ella. serialize() de php sería algo para usar, o podría usar json.cuando finalmente es válida, el sistema ahorraría lugar al correo electrónico (o lo que sea) de mesa, y eliminar el proyecto:
seudo 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'
También podría considerar una mesa draft_file para almacenar archivos adjuntos o fotos para el proyecto, y poder acceder a ellos de forma individual:
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'
modo, un usuario empieza a componer un correo electrónico, tal vez sólo los tipos en el cuerpo, y añade algunos archivos adjuntos. su GUI guarda el correo electrónico en borradores, y carga los archivos adjuntos, los guarda en draft_file y devuelve el borrador del ID y las URL de descarga de los archivos que muestra en su GUI.
él escribe en el Asunto (Hasta sigue en blanco). Su GUI guarda el correo electrónico en borradores, actualizando la tabla de borradores por ID, ya que conoce su ID del paso anterior.
sus usuarios completan el campo Para y presionan Enviar. Su servidor guarda el correo electrónico en la tabla de correo electrónico, copia los archivos adjuntos de draft_file a la tabla email_attachment y borra el borrador, preferiblemente dentro de una transacción.
esto permite borradores a largo plazo, cargas de archivos adjuntos estilo Gmail, manteniendo la integridad de la tabla de entidades reales.
Una pregunta relacionada: [Versión borrador de la tabla de la base de datos] (http://stackoverflow.com/questions/629873/draft-version-of-database-table) –