2009-07-16 55 views
1

我有公司,客戶,供應商等表,它們都有地址信息相關的列。何時將列分隔成新表

我試圖找出我是否應該創建新表的地址「和獨立的地址都列了這一點。

在所有表格上都有地址列很容易使用和查詢,但我不確定從一個好的設計角度來看它是否是正確的方式,將這些相同的列重複在幾張表上讓我好奇。地址

內容是不是對我很重要,我不會檢查或使用上的任何決策過程決定這些地址,他們是純粹的相關信息。目前,我在看有地址信息

回答

6

所有設計問題的答案是這樣的:

這取決於。

所以基本上,在地址的情況下,它取決於你是否有超過1個地址每個客戶。如果您將多於1個,請將其放入新的地址表中,併爲每個地址分配一個CustomerID。這是過度殺傷(大多數時候,這取決於!)來創建一個通用地址表並將其映射到公司/客戶/供應商表。

它也往往矯枉過正(和危險)在你的對象之間的許多一對多的關係映射地址(如地址似乎可以幻化的用戶,如果你這樣做)。

一個大的規則是:保持簡單!

1

如果你只使用自己的表的範圍內,這些地址5桌,有可能是沒有真正的好處將它們轉移到自己的表。

基本上,這聽起來不像是值得的努力。

+0

贊成投票的理由。 thx – 2009-07-16 21:48:40

+1

將它們移動到自己的表格沒有真正的好處,忽略了在一個地方維護單個一致地址模式的價值,而不是將其維護在幾個地方。(當公司和客戶的地址字段長度不一樣時,我發現公司對於與此相關的錯誤瘋狂了。)另外,雙重否定是令人困惑的。 – 2009-07-16 21:54:40

+0

@McWaffle:但是這就是「依賴」的地方。如果你只有2或3個地址的實體,那麼它對你的系統並沒有多大的威脅。如果你有10個使用地址的實體,並且你需要一種將地址本身作爲第一類對象的通用方法,我傾向於同意你的觀點。 – 2009-07-16 21:59:36

1

是的,您應該將地址分隔到自己的表中。知道要問這件事很明智。這裏的關鍵是地址的一般格式是相同的,不管它是誰;客戶,公司,供應商......他們都有相同的地址字段。

這樣做的價值在於將地址視爲原子元素的能力;也就是說,您可以概括所有與地址相關的功能,並只處理一個表,而不用擔心它處理多個表,以及可能發生的相關模式漂移。

0

如果有表之間(在公司和供應商表都進入即同一組織)的重疊,而地址應該永遠是兩個表中是相同的,那麼它可能是值得關在其自己的表移動地址並從其他三張表中獲得外鍵。這樣,你只需要在一個地方更新它就可以了。

如果三個表是彼此完全獨立的,那麼就沒有真正太多從數據移動到另一個表來獲得,所以你還不如不要管它。

4

這被稱爲Database Normalization。是的,如果沒有其他原因,您希望將它們分開,因爲如果您將來需要使用代碼和查詢時會更困難。

作爲一項規則,您應該始終以第三範式設計您的數據庫,即使對於簡單的應用程序(在少數情況下,您不會出於性能或物流原因,但開始時我總是試圖使它是第三範式,然後在知道正確的做法之後學會作弊)。

編輯:爲了擴大這一點,並添加了一些我在其他人的帖子上發表的評論,我認爲當談到代碼和重構它時,複雜和更深入的面向對象的原則將是適當的。但是,重構正在生產的數據庫並不那麼簡單。這都是關於投資回報。從一開始就設計規範化的數據庫非常容易,以證明不這樣做。設計不佳的數據庫的後果可能是災難性的,通常來不及實現這一目標。

0

我認爲這完全取決於數據庫的用途。無可否認,所有的地址信息在結構上都是相同的,並且從理論的觀點來看,所有的地址信息都應該位於通過密鑰從父表格鏈接的單個表格中。

但是從性能和查詢的角度來看,將它們保留在它們各自的表中的確從報告的角度簡化了事情。

我有我目前的公司[物流]其中的地址實際上是邏輯上是相同的情況 - 他們的所有位置,無論他們是否是取貨地點,交貨地點,客戶等

在我的情況,我會說他們絕對應該放在一張桌子上。但是,如果從供應商,客戶,聯繫信息的角度來看它,我會說理論上在一張表中有地址是很好的,但實際上它不會給你一大堆,因爲數據不太可能重複。

0

我不同意戴夫。多對多的方法(地址< - >用戶)既安全又非常有利。

當客戶移動時,地址表中的地址不會改變。而是在地址表中找到新地址,並將客戶等鏈接到該記錄。如果新地址不在表格中,則將其添加到表格中。

那麼地址記錄本身有沒有改變?是的,在這樣的情況下:

  • 事實證明地址有一個錯字
  • 美國郵政服務的更改街道名稱

這些都是非常情況下把所有的地址在一個表沒有重複的回報;任何其他安排都需要一個惱人的重複數據輸入。

當然,如果數據庫被濫用,那麼避免多對多關係會更安全。但是通過這個標記,如果數據庫處於不利的狀態,最好將所有內容打印出來,存儲在文件櫃中,然後根據紙張副本驗證每筆交易。所以在我看來,「防止濫用」並不是一個好的設計原則。