2011-08-22 71 views
0

這可能不是一個「規範化」問題,它更像是我正在保存的數據類型。基本規範化問題

我剛剛完成了一個消息和電子郵件系統的規範。這個想法是我需要保存我的Web服務內部的所有消息,但也知道郵件是否與該消息一起發送。

這是規範。


規範
  • 的任何消息被存儲在一個表中。
  • 消息可以來自未註冊的用戶或註冊用戶。

    1. 未註冊的用戶信息將只是有一個返回電子郵件地址

    2. 註冊用戶的信息將有發送者的用戶ID

  • 的消息或者歸用戶(意味着它們是發送給)或消息由用戶角色共享。

    1. 當消息被用戶所擁有,我們記錄有關此消息的一些信息(同桌的消息)。

      a)用戶是否打開/閱讀消息?

      B)爲一個_ 電子郵件發送 _到消息的所有者或只是內部消息

      C)日期的信息是第一讀

      d)日期被髮送的消息

    2. 當消息被髮送到一組用戶,這意味着它們被髮送到「所有用戶」或「所有業主」或「所有超級管理員」 ......

      一)信息被保存一次Ëmessages表,每個人開放的是在一個單獨的表

      c)一個字段記錄跟蹤的發送日期

      b)如直接_ 郵件已發送 _,或者如果它只是內部保存在系統中。 (單獨的表)

  • 消息可以是帶螺紋的,這意味着,如果一個消息響應,它是兒童或原始消息。

  • 消息有不同的「類型」,這意味着一個消息可以是「系統公告」,「探究」,「個人信息」,「悄悄話」,「交易信息」

  • 鏈接到產品查詢的消息將保存他們正在查詢的產品的ID。 (即相關財產)。

最終規格


現在的實際問題...

正如你可以在子彈1見)(B)我錄製這被髮送到一個消息個人用戶,如果電子郵件也發送了該消息。

但是,當一封電子郵件發送給一組用戶時,我會記錄一封電子郵件是否以完全不同的表格發送。 很明顯,因爲我無法將這些信息保存在同一張表中。

您對此模型有何意見?我沒有複製任何數據,但我分開保存數據的位置。我是否應該有一個email_sent表來記錄所有這些信息。

回答

1

很難說您目前的設計是好還是壞。表面上看,我認爲把同一條信息分成兩個地方是錯誤的。查看錶格中發送的個人電子郵件似乎比較容易,該電子郵件與個人較爲接近,並提供有關發送給離羣組較近的羣組的電子郵件的註釋。但是,您的代碼將不得不在兩個地方查找有關任何電子郵件或關於所有電子郵件的信息。

如果標記email_sent的含義對於單個用戶而言與對於一組用戶是相同的,那麼在兩個地方始終查看基本上是一種信息的內容將是單調乏味的(從代碼的角度來看,它可能會很慢並且很難支持)。

另一方面,它可能是email_sent是對您的交易或報告邏輯並不重要,是一個溫和的有趣的事實,是「來坐騎」。在這種情況下,試圖強制將兩個不同的email_sent標誌集中到一個地方,可能需要一個不方便且不適宜的兩個實體混搭,這兩個實體由於其所有其他更重要的屬性而應該是不同的。

如果不能更好地理解您的業務需求,很難給出確鑿的答案,但這是您必須考慮的折衷。

+0

這不是很在同一條信息兩個地方,我只能保存一次國旗,但同一個「類型」的信息需要保存在兩個地方。我想你明白了,只是很難指出,email_flag只會被保存一次,但如果是單個電子郵件,它在郵件表中,並且如果它是一個組角色電子郵件,則它在單獨的表中。 – Layke

+0

聽起來對我來說,也許你最好將屬性分開,除非您決定將兩種類型的電子郵件放在一張表中更好。決定因素應該是消息表可以/應該一起走,而不是應該將email_sent標誌放在一起。 –

+0

是的,我絕對把每條消息都寫入消息表中。 – Layke

1

創建3個表:

  1. MSG ID爲(鍵自動),MSGTEXT,類型(值U或R),用戶ID /角色ID

  2. ROLES與角色ID,用戶id

  3. ACCS with userId,MsgId,打開日期,閱讀等

MSG記錄我ssage,有型,看它是否從一個角色或註冊用戶

ROLES是指向一個角色,很多用戶

ACCS記錄一切,對於一個用戶,註冊與否。

要檢索,加入味精U型與ACCS

加入味精R型的角色,然後用ACCS

要檢索所有,UNION他們