2016-08-14 28 views
5

Tôi muốn tạo một ứng dụng nhắn tin đơn giản lưu trữ tin nhắn (tương tự như e-mail, nhưng chỉ đơn giản là tin nhắn). Tôi nên thiết kế cơ sở dữ liệu như thế nào?Lưu trữ e-mail trong cơ sở dữ liệu SQL

Bảng Users:

  • Tên đăng nhập (khóa chính)
  • userPassword

Bảng E-mails:

  • EmailId (Khóa chính)
  • Từ (key nước ngoài đến người dùng)
  • Để
  • Chủ đầu tư (key nước ngoài đến người dùng)
  • Chủ đề
  • Time
  • nội dung Email
  • bố trí Email (Có thể nội dung và bố cục trong một lĩnh vực? XAML)

Vì một e-mail có thể được gửi tới nhiều người, cách tốt nhất để lưu trữ cột là gì? Tôi có nên chỉ cần đặt nó như là một chuỗi, phân cách bằng dấu phẩy, sau đó lấy tất cả người dùng với một hàm trong mã của tôi? Hoặc là có cách nào tốt hơn để đi về điều này?

+0

Nếu tất cả người nhận nằm trong mô hình (để thông báo ra bên ngoài), thì bạn nên lưu trữ chúng dưới dạng bảng tham chiếu, chứ không phải bên trong bảng thông báo. Bằng cách đó, bạn có thể phân tích cú pháp mục nhập và tất cả các địa chỉ luôn được cập nhật. – arkascha

+3

Và nói chung không, chỉ để đảm bảo bạn nhớ rằng: Bạn nên _never_ lưu trữ mật khẩu người dùng bên trong cơ sở dữ liệu. – arkascha

+0

@arkascha Tôi phải lưu trữ mật khẩu trong cơ sở dữ liệu, như băm không may. – user3117628

Trả lời

5

Bảng Users

  • Tên đăng nhập (khóa chính)

  • userPassword

Bảng E-mail

  • EmailId (Khóa chính)

  • Từ (key nước ngoài đến người dùng)

  • Chủ đề

  • Time

  • nội dung Email

  • bố trí Email (Có thể nội dung và bố trí trong một trường?XAML)

Bảng Email_Recipients

  • Recipient ID (Primary Key)

  • RecipientUserID (key Ngoại từ tài khoản Bảng)

  • EmailId (key Ngoại từ Email Bảng)

  • RecipientType // loại có thể thực tế, CC, BCC

bảng khác có thể được tạo ra của EmailRecipientTypes

Giống như Bảng EmailRecipientTypes

  • typeid (Primary Key)
  • LoạiName // có thể là Thực tế, CC hoặc BCC

Bằng cách này bạn có thể thay đổi Email_Recipients Bảng như

Bảng Email_Recipients

  • Recipient ID (Primary Key)
  • RecipientUserID (key Ngoại từ tài khoản Bảng)
  • EmailID (Khóa nước ngoài từ Bảng email)
  • RecipientTypeID (khóa ngoại fr om Bảng EmailRecipientTypes)

Mặc dù bảng thứ tư sẽ chỉ chứa 3 hồ sơ nhưng nó sẽ giúp trong việc giảm trong sao chép dữ liệu và sẽ giúp bạn trong nhóm email trong một số cách cần thiết mà bạn muốn (nó một thể)

+0

Cảm ơn bạn, câu trả lời tuyệt vời! – user3117628

+0

Bạn được chào đón :) Rất vui được trợ giúp :) –

6

Bảng Users

  • UserId
  • Tên đăng nhập
  • Mật khẩu

Bảng Email

  • EmailId
  • Từ (key nước ngoài đến UserId)
  • Chủ đầu tư (key nước ngoài đến UserId)
  • Chủ đề
  • EmailContent
  • EmailLayout
  • Time

Bảng nhận

  • Id
  • Email (key Ngoại tới EmailId)
  • Để (key nước ngoài đến UserId)

Vì vậy, những người nhận email có liên quan đến email như một nhiều với một bản đồ.

Bằng cách này bạn có thể chọn tất cả những người nhận email bằng cách chọn tất cả các hàng trong bảng Recipients với thích hợp EmailId

Ví dụ một email được gửi đến 2 người dùng sẽ có hàng (như là một ví dụ)

--------------------------- 
| Id | Email | To  | 
--------------------------- 
| 1 | 1  | 3 (User1) | 
--------------------------- 
| 2 | 1  | 4 (User2) | 

Is storing a delimited list in a database column really that bad? Đưa ra ví dụ tốt về lý do tại sao sử dụng giá trị được tách nhau bằng dấu phẩy trong bảng cơ sở dữ liệu là thực tiễn không tốt.

Các vấn đề liên quan