2011-01-10 68 views
2

我想知道我有一個基本的數據庫設計/數據類型問題。數據庫優化:什麼是更快的搜索整數或短字符串?

我有一個名爲「experience_required」字段的porjects表。我知道這個領域將始終由以下選項之一填充:實習生,初級,高級或導演。隨着時間的推移,這個列表可能會有所不同,但我不希望其上的項目發生重大變化。

我應該去整數或字符串?在將來,當我有大量這樣的記錄並需要通過exirence_required檢索它們時,將它們整體化會有所不同嗎?

回答

2

肯定會通過字符串進行整數。

性能會更好,您的數據庫將更接近標準化。

最終,您應該創建一個名爲ExperienceLevel的新表,其中包含字段Id和標題。現有表中的experience_required字段應該更改爲另一個表上的外鍵。

這將是一個更強大的設計,並且在您更改可用體驗級別或決定重新命名體驗級別的情況下將更加寬容。

您可以閱讀更多關於Normalization here

+0

整數或字符串的選擇將如何對數據庫的規範化產生任何差異? – 2011-01-10 22:46:41

+0

@Larry:你說得對,不會是這樣,除非你做外鍵。我已經改變了違規的句子 - 謝謝:) – 2011-01-10 22:48:56

+0

即使使用外鍵,使用自然文本鍵或代理整數鍵的實現細節也不會影響數據庫的規範化程度(或設計質量)。 – 2011-01-10 22:49:59

1

整數。字符串應該只用於存儲文本數據(名稱,地址,文本等)。

此外,整數在這種情況下更好的排序,存儲空間和維護。

2

你可能會喜歡這個字段索引。一旦索引整型和小型字符串沒有太多(可忽略不計)的性能差異。

1

從理論上講,整數在索引時會佔用較少的內存。 你也可以使用看起來像字符串但是作爲整數存儲的枚舉(在mysql中)。

1

沒關係。差異可以忽略不計。有什麼區別會有利於整數的選擇,但這是少數我喜歡短文本鍵的情況之一,因爲它會在許多報告情況下將JOIN保存回查找表。

0

爲了渾濁一些水,我會建議混合。以@ GregSansom的想法開始(upvoted),但不是整數使用CHAR(1)數據類型,其值爲I,J,S和D.這會給你與使用tinyint相同的性能,並給出一個簡單記住的額外優點當(如果)直接與數據一起工作時的助記符。有一點用處,記住「S」意味着「高級」,而3沒有任何內在含義 - 特別是如果像你所建議的那樣,隨着時間的推移會增加額外的值。 (例如將5添加爲試用版,並且「低級別=低價值」範例在窗口外面。)

這隻適用於您有非常短的項目列表。獲得太多或太相似,並且很難處理可用代碼。

當然,如果這些是順序值呢?當然聽起來像這裏。在這種情況下,不要讓他們1,2,3,4,使他們10,20,30,40,所以你可以插入稍後新的分類。這也可以讓你輕鬆實現範圍,例如「everyone < 30」(意思是不到「高級」)。

我想我的主要觀點是:瞭解您的數據,如何使用它,它將如何或將會隨着時間的推移而變化,以及相應的計劃和編碼!

相關問題