2009-07-08 158 views
3

我正在使用SQL Express 2008版本。我已經在一張紙上計劃了我的數據庫表/關係,並準備開始。SQL 2008數據類型 - 使用哪些數據類型?

不幸的是,當我點擊我的pkID_Officer數據類型我提供超出我的預期,因此,懷疑已設置。

任何人都可以點我到這些日期類型的解釋和示例的地方給出哪些字段更適合哪些數據類型。

實例:

  • 爲int用於ID(的PrimaryKey)仍是明顯的選擇或不唯一標識符需要它的冠?

  • 電話號碼中的數字用'。'分隔。 (01.02.03.04.05)

  • 電子郵件

  • 項目,這將是超鏈接

  • NCHAR和VCHAR?

任何幫助總是讚賞。

謝謝

Mike。

回答

2

MSDN網站對SQL 2008數據類型有很好的概述。

http://msdn.microsoft.com/en-us/library/ms187752.aspx

對於ID字段使用,如果它需要跨越不同的系統或表中的唯一,或者您希望能夠生成數據庫之外的ID的GUID。否則,int/identity值工作得很好。

我將電話號碼存儲爲字符數據,因爲我不會對它進行計算。我會認爲電子郵件將以相同的方式存儲。

至於超鏈接,基本上可以將超鏈接自身存儲爲varchar,並在客戶端上呈現鏈接或將標記本身存儲在數據庫中。真的取決於具體情況。

如果您認爲現在或未來需要支持雙字節語言,請使用nvarchar。

+0

謝謝。偉大的聯繫。對於這些數據類型,除了眼睛還有更多,但我會從現在開始 - 只需要 - 簡單的基本數據類型。 – RocketGoal 2009-07-08 14:05:36

1

對於主鍵我總是更喜歡(作爲起點)使用自動增量int。它使一切都變得更加有用,並且與實際數據沒有任何「自然」關係。當然,可能也有例外...

0

唯一標識符也是GUID: http://de.wikipedia.org/wiki/Globally_Unique_Identifier

的GUID
- 是全球唯一的 - 在DOTNET的如她自己的對象(System.Guid) - 長16位數

如果你想要這樣的東西,那就用它吧。如果你用int-id很好,那就沒問題。

電話號碼/電子郵件/ Hyperling是正常的字符串。

0

NCHAR/NVARCHR是CHAR/VARCHAR數據類型的Unicode對應點。我幾乎總是在我的應用程序中使用它們 - 除非我有令人信服的理由不使用它們。

1
  • int是一個ID(primarykey)還是顯而易見的選擇還是唯一標識符是皇冠?

我個人比GUID更喜歡INT IDENTITY - 尤其是對於聚簇索引。 GUID在本質上是隨機的,因此導致大量的索引碎片,因此在用作SQL Server上的聚簇索引時性能較差。 INT沒有這個麻煩,再加上它只有4字節,而不是16字節,所以如果你有很多行和很多非聚簇索引(聚簇關鍵字會被添加到每一個非聚簇索引中的每個條目中,聚集索引),使用GUID將不必要的臃腫您的空間需求(在磁盤上,並在你的機器的RAM),其中數字之間用

  • 的電話號碼「」 (01.02.03.04.05)
  • 電子郵件
  • 項目,這將是超鏈接

我會使用字符串字段所有這些。

VARCHAR很好,只要你不需要任何「外來」語言支持,例如對於英語和西歐語言來說沒什麼問題,但對東歐和亞洲語言(西里爾語,中文等)不起作用。

NVARCHAR將以一個價格處理所有這些額外討厭的語言 - 每個字符以2個字節存儲,例如,一串100個字符將使用200個字節的存儲 - 總是。

希望這會有所幫助!

Marc

+0

是的,你說的是一個隨機GUID作爲一個集羣密鑰的問題。但是,關於使用guid作爲主鍵的問題,應該注意的是,它可以作爲主鍵而不被聚集。 – sisve 2009-07-08 14:19:02

相關問題