2009-06-07 96 views
1

我正在創建一個與聯繫人表(我存儲名字,姓氏等)相關的新表。需要幫助命名字段(和表)

表有:

int Id (PK, Identity) 
int ContactId (FK) 
int Type (this identifies whether the following is an email, tel, fax etc.) 

nvarchar(40) [I need a name for this one] 

將nvarchar的領域基本上是存儲或者[email protected],或+1 567 555-2934×12,或任何其他人會的方式來聯繫某人進入其他。電子郵件,電話,IM名稱,傳真號碼等。

我不知道如何命名該字段或包含這些東西的表。我無法將其命名爲「emailAddress」,因爲它可能是電話號碼,反之亦然。我當然不想將它命名爲「emailOrPhoneOrXYZ」。

有什麼想法?

回答

1

那麼,我可能會從重命名「Id」和「type」開始 - 這些描述不是很明確。 「ContactInfoID」和「ContactInfoType」如何?最後的字段可以合理地標題爲「ContactInformation」。

你說得對,你不應該使用像「emailOrPhoneOr ......」一個愚蠢的名字,因爲從存儲其他類型的在未來的聯繫人信息,禁止你。

也認爲這是一個TINYINT可能比足夠大,你的「類型」字段,前提是你的RDBMS支持tinyints更多。

+0

我使用Id和ContactId,因爲我使用的DTO和LINQ已經命名它是什麼(類名),而ContactInfo.ContactInfoId會複製它。 ContactInfo.Id更好。 關於tinyint你是對的,我實際上使用tinyint,但並沒有理會這個例子,因爲它不會與問題相關。不管怎麼說,多謝拉!現在我只需要一個關於如何命名該字段的答案,我問了一下:) – Alex 2009-06-07 04:04:06

+0

對,你可以把它稱爲「ContactInformation」嗎?這是非常具有描述性的,並清楚地表明該字段包含的內容。我傾向於反對像「價值」或「細節」之類的通用列名稱 - 他們並不完全解釋您正在查看的是什麼樣的價值或細節,並且可能錯誤地暗示「價值」在此表涉及另一個表中的「價值」 - 幾乎肯定不會如此。 – 2009-06-07 04:10:23

3

我有一個類似的問題,我正在開發的sysytem表。

所以我們命名的表ContactComplements和現場簡單Value

+0

+1我會以'價值'去,簡單,簡單並達到目的。 – 2009-06-09 09:19:52

1

Contacts表的情況下,你可以考慮爲Detail領域。

0

我只想將它命名爲聯繫人。它的通用性足以適用於任何信息的實際類型,但也意味着它用於聯繫某人。

0

當您維護與CONTACT表關聯的鍵/值對時,可以將其命名爲CONTACT_PROPERTIES。 「價值」與所涉領域的名稱一樣好。

1

理想情況下,設計關係數據庫時,應儘可能避免在同一字段中存儲不同類型的信息。

有一點要考慮,有次在有意義非規範化你的數據,你應該可以考慮,在這種情況下。 (見http://en.wikipedia.org/wiki/Denormalization

至少,我認爲這將是有意義的使用至少2個表,一個用於電子郵件/即時通訊,一個用於手機。對於電子郵件/即時消息表,添加指示地址是電子郵件還是即時消息(或兩者都設置)的標誌,因爲雅虎和其他人使用電子郵件作爲即時消息ID。

1
--table-per-class strategy: 

--baseclass 
table ContactItem 
    column Id --pkey 

--subclass 
table ContactItemEmail 
    column Id --pkey, fkey ContactItem.Id 
    column Email 

--subclass 
table ContactItemPhone 
    column Id --pkey, fkey ContactItem.Id 
    column Phone 
1

我會列出表ContactDetails和字段ContactString

0

據推測,這是一個沒有相關聯的域值的驗證自由文本元素即用戶可以在這裏輸入任何東西,這將是一個可接受的價值。在我們的數據字典中,我們傾向於稱這些'筆記'。