2010-08-20 19 views
0

我有一個數據庫,其中幾個表有一列email用於存儲電子郵件地址。因爲這是調查,很多值將相同,更可能相同的名稱,地址等我的數據庫中應該有一個主郵件地址表嗎?

我應該只有一個主Emails表,然後email_id列?這樣,我只能存儲一次電子郵件字符串,而不是在表格中多次存儲。但是,如果我想確保我只存儲了唯一的電子郵件地址,那麼索引是否會檢查字符串的唯一性並不存在一些限制,因此我可能會存儲多個長電子郵件地址的副本?

在調查數據庫中,我們存儲他們提交的電子郵件地址。如果他們選擇加入郵件列表,我們將這些郵件列表(每個會員一封電子郵件)存儲在郵件列表成員表中,因此該表中可能會有多個相同的地址,具體取決於他們加入的俱樂部數量。現在我添加一張表來跟蹤反彈電子郵件,因爲這是電子郵件地址的屬性,而不是調查或郵件列表成員資格。我在想,「這是很多字符串連接!」

這是「One True Lookup Table」的一種形式嗎?

回答

6

我應該只有一個主電子郵件表,然後是一個email_id列嗎?

這實際上並不重要。

對索引檢查字符串唯一性的長度沒有限制,因此我可能會存儲多個長電子郵件地址的副本?

不,沒有限制。獨特意味着獨特,而不是「某些隨機限制所特有的」。

我在想:「這是很多字符串連接!」

那麼,字符串連接並不是非常緩慢。如果您可以證明這些字符串連接是您應用程序中最糟糕的瓶頸,那麼用整數FK替換字符串連接可能會加快速度。

直到你可以證明這些字符串連接是你最糟糕的問題,不要擔心它們。

擔心如何使用電子郵件地址獲取業務規則。直到你能證明你有問題時才進行優化。

+0

我聽到你在說什麼,但是當這些瓶頸成爲問題時,整個現場運行的應用程序就建立在他們身邊,要說服老闆讓我花費大量時間仔細解構網站上的所有內容都存在停機,數據丟失等風險,只是爲了在事件成爲問題時將事情做好。我已經不喜歡我的加入反彈;會有未來的表格! 事實是,我正在開發*現在*,我可以正確*現在*,如果我確實做得正確,現在,我不會在晚些時候打開病人檢索鑷子。 – user151841 2010-08-20 16:45:02

+0

@ user151841:有很多事情可以浪費時間在*現在*。你可以浪費時間微調'++'操作符。你可以浪費時間微調優化以'<或'<='結尾的循環。在瓶頸進行字符串比較時,情況不會突然停止運行。你會注意到退化,做分析,發現問題。所有性能優化都涉及重寫。最初不應該進行性能「優化」。獲取數據模型** ** **。這是最重要的。 – 2010-08-20 18:34:07

0

如果問題是簡單的「會員有電子郵件地址」,那麼我會保留與會員直接關聯的電子郵件地址,而不是將其標準化爲電子郵件表格。這是因爲並非所有「成員」都必須共享電子郵件。

  • 如果(別問我爲什麼,我不明白 最終用戶)兩大承包商,客人 共享相同的電子郵件地址,當他們中的一個人改變他們的 地址會發生什麼 - 但另一個 不想?

  • 第二種情況,如果我的系統中有兩個成員資格,兩個成員資格都與 同一電子郵件地址,然後我想將其中一個更改爲不同的地址? (不要問我爲什麼,我是一個最終用戶,我已經說了,我不明白最終用戶。)

這將包括一個非常簡單和直接的局面。如果您的系統不同,以至於您需要更多或更嚴格的電子郵件控制,規範化可能適用於您。訣竅在於,從數據的角度來看,它是否重複可以進行標準化的數據,或者是恰好包含一些重複值的「不同」數據。

Bounceback電子郵件表適用於任何一種方式,因爲它是一種單獨的數據(或電子郵件地址)。

至於字符串和索引長度,現在如果RDBMS聲稱它可以索引或唯一索引一個字符串到X個字符(電子郵件地址獲得多長時間?),您可以依靠它來這樣做。它可能不會執行得太快,因爲它必須處理4個字節(典型整數存儲大小)的X個字節的數據,但它可以工作。

+0

我知道有些東西是我忽略的......我們無法更改電子郵件地址:(其中一個要求是一個電子郵件地址可以註冊孩子或配偶:P – user151841 2010-08-20 15:09:31

+0

呃,我們必須按名稱+電子郵件地址。 – user151841 2010-08-20 16:47:44

相關問題