điều này áp dụng cho nhiều email hơn ...
Tôi đã thay đổi ý định về điều này. Cách tốt nhất là sử dụng cột is_draft trong bảng của bạn và lưu trữ cả bản nháp và thực thể hợp lệ trong cùng một bảng. điều này có lợi thế của thực thể giữ cùng một id ngay cả khi nó chuyển vào và ra khỏi trạng thái dự thảo (bạn có thể muốn chỉnh sửa nó sau khi bạn lưu nó, nhưng tạm thời loại bỏ một giá trị bắt buộc). nó sẽ gây nhầm lẫn cho người dùng nếu họ cộng tác trên cùng một tài liệu và id tiếp tục thay đổi, amirite?
bạn sẽ sử dụng is_draft = 1 để tắt quy tắc xác thực ORM, xác thực trình kích hoạt hoặc kiểm tra ràng buộc để cho phép đối tượng không hợp lệ lưu. có, bạn có thể phải cho phép các trường không có giá trị trong bảng của bạn.
quy trình: cố gắng lưu đối tượng. xác thực không thành công. set is_draft = 1 và thử lưu lại. nó tiết kiệm. đặt "DRAFT" lớn lên màn hình ở đâu đó :)
người dùng điền vào thông tin bắt buộc. cố gắng lưu đối tượng. xác thực vượt qua. set is_draft = 0. nó tiết kiệm.
bây giờ, về email và bài đăng trên blog, máy chủ của bạn không được cố gắng gửi hoặc đăng nó ngay lập tức trừ khi người dùng nhấn nút lưu/đăng, nhưng đó thực sự là vấn đề khác.
OLD ĐÁP
Vấn đề là một dự thảo có thể không có giá trị, và không thể được lưu trong bảng thực tế. Ví dụ: giả sử bảng của bạn yêu cầu đối tượng không phải là rỗng, nhưng người dùng chưa điền vào.
Có một cách để có một bảng dự thảo và lưu trữ phiên bản thực thể được sắp xếp theo thứ tự (và con của nó). php serialize() sẽ là thứ gì đó để sử dụng, hoặc bạn có thể sử dụng json.khi nó là cuối cùng hợp lệ, hệ thống sẽ tiết kiệm thay vì vào email (hoặc bất kỳ) Bảng, và xóa bản nháp:
giả 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'
bạn cũng có thể xem xét một bảng draft_file để lưu trữ file đính kèm hoặc ảnh cho bản nháp và có thể truy cập chúng riêng lẻ:
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'
vì vậy, người dùng bắt đầu soạn email, có thể chỉ là các loại trong phần nội dung và thêm một số tệp đính kèm. gui của bạn lưu email vào thư nháp và tải lên tệp đính kèm, lưu chúng vào draft_file và trả về id dự thảo và url tải xuống cho các tệp mà bạn hiển thị trong gui của mình.
anh ấy nhập vào Chủ đề (Để trống). Gui của bạn lưu email vào bản nháp, cập nhật bảng nháp theo id, vì nó biết id của nó từ bước trước đó.
người dùng của bạn điền vào trường Đến và truy cập Gửi. Máy chủ của bạn lưu email vào bảng email, sao chép các tệp đính kèm từ draft_file vào bảng email_attachment và xóa bản nháp, tốt nhất là trong giao dịch.
điều này cho phép các bản nháp dài hạn, tải lên tệp đính kèm kiểu gmail, đồng thời duy trì tính toàn vẹn của bảng thực thể thực của bạn.
Câu hỏi liên quan: [Phiên bản nháp của bảng cơ sở dữ liệu] (http://stackoverflow.com/questions/629873/draft-version-of-database-table) –