性能 - 詮釋與Char（3）

我有一個表，我正在辯論2種不同的方式來存儲信息。它有像這樣性能 - 詮釋與Char（3）

INT ID

INT FK_id

VARCHAR（50）INFO1

VARCHAR（50）INFO2

VARCHAR（50）INFO3
的結構
int forTable or char（ 3）forTable

的FK_id可以是一個外鍵6個表中的一個，所以我需要另一個領域，以確定它是哪個表。

我看到兩個解決方案：

一個整數，它是一個FK到有其實際值設置表。
帶有表格縮寫版本的char（3）字段。

我想知道如果任何人都知道，如果一個會更有益的速度明智比其他或有將使用CHAR（3）

注意什麼大問題：我將創建一個索引查看該字段的6個不同值。這個表格將包含約30k行，需要連接更大的表格

來源

2010-02-18 corymathews

表定義的第一行是什麼意思？ ** int id int FK_id varchar（50）** – 2010-02-18 19:30:20

因此，FK值可以是6個其他表中的1個PK？ – 2010-02-18 19:31:39

@KM這意味着編輯找到了我。現在修復它。 @iKnowKungFoo正確。這是因爲它在每個表中都是相同的信息，但我需要能夠訪問它的任何一個，而不必將6個表中的每個表聯合起來。 – corymathews 2010-02-18 19:33:13

在這種情況下，它可能不除整理開銷（A VS a VS ä VA à）關係

我會使用CHAR（3），說像瑞士法郎，英鎊等貨幣代碼但如果我的自然關鍵是「瑞士法郎」，「英鎊」等，我會拿數字。

3字節+整理vs 4字節數字？你需要一個十億行或運行一箇中等規模的國家才能實現...

來源

2010-02-18 19:33:04 gbn

你有沒有考慮過使用TinyInt。只需要一個字節來存儲它的值。 TinyInt的值範圍在0到255之間。

來源

2010-02-18 19:30:58

沒有專門查看數據我怎麼知道哪個數字與哪個表一起使用？特別是從現在起一個月左右。還有，這只是一個正常的int，這是一個FK的設置表，將包含相應的表的名稱有很多好處？ – corymathews 2010-02-18 19:42:07

只有約30K行，可能根本沒有太大的差別。事實上，我懷疑你會注意到int，small int，tiny int或char（3）之間的任何區別。此外，如果您在此表中只有6個不同的值，那麼它可能不足以成爲索引中第一列的合適候選者。 – 2010-02-18 19:46:39

我認爲這裏需要一個小整數（tinyint）。一個「縮寫版」看起來太像一個幻數。

我也認爲性能明智的整數應擊敗char（3）。

來源

2010-02-18 19:31:24

簡寫版本對於人員或類似用戶來說可能是「ppl」。 – corymathews 2010-02-18 19:40:45

首先，一個50個字符的ID不是全球唯一的，聽起來有點可怕。這些ID有一些意義嗎？如果沒有，你可以很容易地獲得一個GUID在更少的空間。就我個人而言，我是一個儘可能讓事情變得人類可讀的風扇。我會，並且已經把圖的全名放在圖表中，直到我需要做其他事情。我的偏好是儘可能爲每個可能的相關表格建立鏈接表。

除非你正在談論真正的大規模，否則你最好減少ID的大小，併爲表的名稱增加幾個字符。對於真正的大規模，我會減少ID的大小並使用一個整數。

雅各

來源

2010-02-18 19:33:08 TheJacobTaylor

對不起編輯器（或我）的jacob在編寫時有點混亂。 PK是一個整數自動增量字段。 varchar50不應該在該行上。不知怎的，它被錯誤地放置了，我很快就錯過了它。 – corymathews 2010-02-18 19:35:56

Gotcha。 32位與100字節有點不同。我認爲從速度角度來看，整數比較是單個CPU指令。字符串比較通常是多個（每個字符至少一個）。雖然他們可以同時處理，但我不知道他們這樣做。 – TheJacobTaylor 2010-02-19 05:14:36

因爲你的FK不能被強制執行（因爲它是根據類型的變體）的數據庫約束，我會認真考慮重新評估你的設計中使用鏈接表，其中每個鏈接表包括兩個FK列，一個到實體的PK，一個到6個表中的一個的PK。

雖然這看起來有點過分，但它使許多事情變得更簡單，添加新的鏈接表並不比調整新的FK類型更復雜。另外，它更容易擴展到一個實體需要比單個表格更多的1-1關係，或者需要與其他6個實體有多個1-1關係的情況。

在不斷變化的，FK情況下，你可以失去數據庫一致性，可以忽略對類型代碼過濾器聯接到錯誤的實體等

我要補充一點，鏈接表的另一個巨大的好處是，您可以鏈接到具有不同數據類型鍵（int，自然鍵等）的表格，而無需添加超順序鍵或將鍵存儲在容易出現問題的varchar或類似的解決方法中。

來源

2010-02-18 21:40:01

或者如果你不使用或不能鏈接表（這是我同意的想法），那麼你需要一個觸發器來保持數據的完整性，因爲你不能將一個字段設置爲FK到6個不同的表。 – HLGEM 2010-02-18 21:49:47

是否需要單個表的原因是，您希望確保當六個父表引用保證爲相同實例的子行的給定實例？這是經典的「多親」問題。您可能遇到的一個例子是地址或電話號碼與多個人/聯繫人表。

我能想到幾個選項：

選擇1：每個父表的鏈接表。這將是Hoyle架構。所以，像這樣：

Create Table MyTable(
        id int not null Primary Key Clustered 
        , info1 varchar(50) null 
        , info2 varchar(50) null 
        , info3 varchar(50) null 
        ) 

Create Table LinkTable1(
         MyTableId int not null 
         , ParentTable1Id int not null 
         , Constraint PK_LinkTable1 Primary Key Clustered(MyTableId, ParentTable1Id) 
         , Constraint FK_LinkTable1_ParentTable1 
          Foreign Key (MyTableId) 
          References MyTable (Id) 
         , Constraint FK_LinkTable1_ParentTable1 
          Foreign Key (ParentTable1Id) 
          References ParentTable1 (Id) 
         ) 
... 
Create Table LinkTable2...LinkTable3

選擇2.如果你知道，你永遠不會有超過說的六個表，並願意接受一些非規範化和設計的fugly，你可以增加6個外鍵的主表。這樣可以避免填充一堆鏈接表的問題，並確保正確的引用完整性。但是，如果父母的數量增加，那麼這種設計可能會很快失去控制。

如果您滿足於您現有的設計，那麼就字段大小而言，我會使用完整的表名稱。坦率地說，char（3）和varchar（50）甚至varchar（128）之間的性能差異對於您可能放入表中的數據量而言可以忽略不計。如果你真的認爲你將擁有數百萬行，那麼我會強烈考慮鏈接表的選項。

如果您想保持您的設計並希望獲得最佳性能，那麼我將使用帶有外鍵的tinyint指向包含帶tinyint主鍵的六個表的列表的表。這可以防止數字變得「魔術」，並確保您縮小父表的列表。當然，它仍然不能防止孤立的記錄。在這個設計中，你必須使用觸發器來做到這一點。

來源

2010-02-19 05:31:31 Thomas

您能提供一個鏈接或更多關於「Hoyle架構」的細節描述嗎？除此之外，我找不到其他說明。 – StingyJack 2014-07-30 15:47:48

性能 - 詮釋與Char（3）

回答

相關問題