2012-06-29 43 views
0

我正在設計一個數據庫,它將存儲關於一些藝術家的信息。這些藝術家可以屬於一個或多個組織。從這些組織中,我只想存儲他們的名字,並且我正在考慮與這些組織建立一個表格,這些組織只有名稱作爲主鍵而沒有別的。是否只有一個表的主鍵是一個概念性錯誤?在這種情況下,我會欣賞一些建議來解決這個問題。只有主鍵字段的表有一個概念錯誤?

+0

不,一切都很好,只要兩個組織不能有相同的名稱。 –

回答

1

您想要一個OrganizationId來處理組織名稱更改的情況。

您可能還會遇到不同組織似乎具有相同名稱的情況。有多少「現代藝術博物館」? (對紐約客來說,只有一個;-)

您的組織表可能會隨着時間的推移而擴大,包括短名稱,地址,聯繫人,首選語言等字段。所以,這個表應該是這樣的:

create table Organizations (
    OrganizationId int not null identity(1,1), 
    Name varchar(255), 
    CreatedBy varchar(255) default system_user, 
    CreatedAt datetime default getdate() 
) 

在一個成熟的數據庫,你甚至會認識到,企業名稱變更,合併,有時分開。您可以通過向記錄添加生效日期和結束日期來處理此問題。

+0

好吧,我想我會用這個解決方案。謝謝,這非常有用。 – JavierElBene

0

這樣的標準做法是爲藝術家設置1個表格,爲組織創建1個表格,並將1個關聯表格與藝術家與1個或多個組織關聯起來。

ARTIST (id, firstName, lastName) 

ORGANIZATION (id, name) 

ARTIST_ORGANIZATION(artist_id, org_id) 

即使組織名稱可能/應該是唯一的,這是很好的有一個數字ID作爲主鍵,以便你可以做關聯。查詢與id的關聯比搜索字符串更好。

4

事實上,只有主鍵的關鍵字有一個表的概念錯誤?

不是本身。有完全合法的情況下,所有的領域都包含PK。

在這種特殊情況下,組織名稱的關鍵,但是,這並不一定意味着它應該是鍵 - 你可以「發明」的另一個關鍵是小(通常爲整數),更容易保持並小學,像這樣:

enter image description here

organizarion_id被稱爲「代理鍵」,侗族的一些優點,其中包括:

  • 孩子FKs會更苗條(因爲只有整數被遷移到孩子,而不是整個字符串)。
  • 您可以更新organization_name而不更新organization_id,因此不會將此更新級聯到子級。
  • 一個小整數替代項可能比一個更復雜的自然鍵更適合於ORM。

缺點:

  • 可能需要更多的加盟。
  • 需要一個索引,並且每個附加索引都會帶來開銷(即使在基於堆的表中,但特別是在clustered tables中)。

正如你所看到的,這是一個平衡的問題,你是唯一一個有足夠的領域知識做出正確決定的人。

注意:organization_artist中的字段順序很重要。如果您需要高效地查詢給定組織的藝術家並在需要某個給定藝術家的組織時將其撤銷,請使用上面顯示的順序。如果您需要兩個方向,則需要在這兩個字段(PK下方的索引旁邊)使用另一個複合索引,但順序相反。如果您只能使用一個索引,請考慮將此表集羣化(如果您的DBMS支持它)。