Le migliori pratiche per le bozze di salvataggio automatico?

Question

Qual è la migliore strategia per le applicazioni che salvano automaticamente una e-mail prima di essere inviate o salvano un post del blog prima che sia finito o ufficialmente salvato? Sarebbe meglio usare una tabella separata nel database per le bozze temporanee o avere una colonna di stato che contrassegni un post come bozza o pubblicato? Non sto cercando codice, solo metodi, ma qualsiasi altro consiglio correlato sarebbe ben accetto, come la frequenza di salvataggio, ecc.

Answer 1

Considerando che tabelle separate per bozze e articoli pubblicati sarebbero essenzialmente duplicate l'una dell'altra , Mi sporgerei verso un solo tavolo con una colonna di stato per distinguere tra i due.

Answer 2

Realizzo in modo Wikipedia: salvo la prima versione e tutte le modifiche salvate (in base al tempo o al comando utente esplicito) come versione successiva. Dopo es. pubblicazione è possibile eliminare la bozza del grafico - oppure no.

Se si salvano i dati nel database, penso che sia opportuno utilizzare la stessa tabella (è possibile evitare conflitti di schemi) e utilizzare la versione/lo stato per tracciare il ciclo di vita delle bozze.

Answer 3

questo vale per più di messaggi di posta elettronica ...

ho cambiato idea su questo. Il modo migliore è utilizzare una colonna is_draft nella tabella e archiviare entrambe le bozze e le entità valide nella stessa tabella. questo ha il vantaggio dell'entità che mantiene lo stesso id anche se entra e esce dallo stato di bozza (potreste volerlo modificare dopo averlo salvato, ma rimuovere temporaneamente un valore richiesto). sarebbe confuso per gli utenti se stessero collaborando allo stesso documento e l'id continuasse a cambiare, amirite?

si utilizza is_draft = 1 per disattivare le regole di convalida ORM, attivare le convalide o controllare i vincoli per consentire a un oggetto non valido di salvare. sì, probabilmente dovresti consentire campi nullable nella tua tabella.

processo: tenta di salvare l'oggetto. la convalida fallisce. imposta is_draft = 1 e prova a salvare di nuovo. salva. metti un grande "DRAFT" sullo schermo da qualche parte :)

utente inserisce le informazioni richieste. prova a salvare l'oggetto. passaggi di convalida. imposta is_draft = 0. salva.

ora, per quanto riguarda i messaggi di posta elettronica e blog, il tuo server non dovrebbe provare a inviarlo o postarlo immediatamente a meno che l'utente non prenda il pulsante salva/pubblica, ma questo è un altro problema.

---

risposta Old

Il problema è che un progetto potrebbe non essere valido, e non può essere salvato nella tabella effettiva. Ad esempio, supponi che la tua tabella richieda che il soggetto non sia nullo, ma l'utente non l'ha ancora compilato.

Un modo sarebbe avere una tabella di bozze e memorizzare una versione serializzata dell'entità (e dei relativi figli) su di essa. serialize di php() sarebbe qualcosa da usare, o potreste usare json.quando è finalmente valida, il sistema salva invece l'e-mail (o altro) da tavolo, ed eliminare il progetto:

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' 

si potrebbe anche prendere in considerazione un tavolo draft_file per memorizzare allegati o le foto per il progetto, ed essere in grado di accedervi individualmente:

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 utente avvia la composizione di una e-mail, forse solo i tipi nel corpo, e aggiunge alcuni allegati. il tuo gui salva l'e-mail nelle bozze e carica gli allegati, li salva in draft_file e restituisce l'id di bozza e gli url di download per i file visualizzati nella tua GUI.

digita nell'oggetto (A è ancora vuoto). Il tuo gui salva l'e-mail alle bozze, aggiornando la tabella delle bozze con id, poiché conosce il suo id dal passaggio precedente.

gli utenti riempiono il campo A e fanno clic su Invia. Il server salva l'e-mail nella tabella e-mail, copia gli allegati da draft_file nella tabella email_attachment ed elimina la bozza, preferibilmente all'interno di una transazione.

questo consente di eseguire bozze a lungo termine, caricamenti di allegati in stile Gmail, mantenendo l'integrità della tabella delle entità reali.