dies gilt für mehr als E-Mails ...
wechselte ich auf diesen einen Sinn. Der beste Weg besteht darin, eine is_draft-Spalte in Ihrer Tabelle zu verwenden und sowohl Entwürfe als auch gültige Entitäten in derselben Tabelle zu speichern. Dies hat den Vorteil, dass die Entität die gleiche ID behält, auch wenn sie den Entwurfsstatus wechselt oder nicht (Sie möchten sie möglicherweise bearbeiten, nachdem Sie sie gespeichert haben, aber einen erforderlichen Wert vorübergehend entfernen). es wäre für die Benutzer verwirrend, wenn sie am selben Dokument mitarbeiten würden und sich die ID ständig ändert, Amirite?
Sie würden is_draft = 1 verwenden, um ORM-Validierungsregeln zu deaktivieren, Validierungen auszulösen oder Einschränkungen zu prüfen, damit ein ungültiges Objekt gespeichert werden kann. Ja, Sie müssten wahrscheinlich nullfähige Felder in Ihrer Tabelle zulassen.
Prozess: versuchen, Objekt zu speichern. Validierung schlägt fehl. Setze is_draft = 1 und versuche erneut zu speichern. es spart. Setzen Sie große "ENTWURF" auf dem Bildschirm irgendwo :)
Benutzer füllt die erforderlichen Informationen. versuche das Objekt zu speichern. Validierung passiert. setze is_draft = 0. es spart.
jetzt, in Bezug auf E-Mail und Blog-Posts, sollte Ihr Server nicht versuchen, es zu senden oder sofort posten, es sei denn, der Benutzer die Schaltfläche Speichern/Post, aber das ist ein anderes Problem wirklich.
ALTE ANTWORT
Das Problem ist, dass ein Entwurf nicht gültig sein könnte, und kann nicht in der eigentlichen Tabelle gespeichert werden. Angenommen, Ihre Tabelle fordert, dass das Thema nicht null ist, aber der Benutzer es noch nicht ausgefüllt hat.
Eine Möglichkeit wäre, einen Draft-Tisch zu haben und eine serialisierte Version der Entity (und ihrer Child-Elemente) zu speichern. php's serialize() wäre etwas zu verwenden, oder Sie könnten json verwenden.wenn es endlich gültig ist, würde das System stattdessen an die E-Mail speichern (oder was auch immer) Tabelle, und löschen Sie den Entwurf:
Pseudo-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'
Sie auch eine draft_file Tabelle zum Speichern von Anhängen in Erwägung ziehen könnte oder Fotos für den Entwurf und in der Lage sein, sie einzeln zuzugreifen:
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'
so beginnt ein Benutzer eine E-Mail verfassen, vielleicht auch nur Typen im Körper, und fügt einige Anhänge. Ihre GUI speichert die E-Mail in Entwürfen und lädt die Anhänge hoch, speichert sie in draft_file und gibt die Entwurfs-ID sowie die Download-URLs für die Dateien zurück, die Sie in Ihrem GUI anzeigen.
Er gibt den Betreff ein (To ist noch leer). Ihre GUI speichert die E-Mail in Entwürfen und aktualisiert die Draft-Tabelle nach ID, da sie ihre ID aus dem vorherigen Schritt kennt.
Ihre Benutzer füllen das Feld An aus und drücken Senden. Ihr Server speichert die E-Mail in der E-Mail-Tabelle, kopiert die Anhänge aus draft_file in die Tabelle email_attachment und löscht den Entwurf, vorzugsweise innerhalb einer Transaktion.
Dies ermöglicht langfristige Entwürfe, Gmail-ähnliche Anlagen-Uploads, während die Integrität Ihrer realen Entitätstabelle erhalten bleibt.
Eine verwandte Frage: [Entwurfsversion der Datenbanktabelle] (http://StackOverflow.com/questions/629873/Draft-version-of-Database-Table) –