我可以限制SQL Server列中的特定字符嗎？它會提高大小和查詢速度嗎？

我無法弄清楚我所要求的正確術語，所以我很抱歉，如果這是錯誤的地方或格式。我可以限制SQL Server列中的特定字符嗎？它會提高大小和查詢速度嗎？

我正在重建數據庫，稱之爲aspsessionsv2。它由一個擁有超過110億行的單個表組成。第1列是一個字符串，除20個字符外沒有其他限制。其他列都包含十六進制數據......所以沒有任何理由讓該字段存儲A-F和0-9以外的字符。所以...

有沒有一種方法可以配置SQL Server將字段限制爲這些字符？
這會減少數據庫的整體大小嗎？
這會加快查詢這個大小的數據庫嗎？

是什麼讓我想到這是WinRAR。我將只包含HEX字符的50GB文件壓縮到206MB。即使我理解它是如何工作的，這也讓我感到很頭疼，所以我很好奇，如果我可以在SQL Server數據庫上做同樣的「壓縮」。

謝謝！

因爲我提出了一個問題，所以有點過了。以下是一些技術信息：Windows Server 2008 R2，SQL Server 2008,10列，110億行

來源

2015-11-01 Jason Paw

發佈實際的「CREATE TABLE」爲你的餐桌可以澄清你的意思是「HEX數據」（因爲根據我的知識，SQL中沒有這種類型）。 –

您是否嘗試過（var）二進制數據類型？ –

我正在測試所有三個明天，但varbinary的聲音非常有希望！ –

您可以使用blob（二進制大對象），它將十六進制數據字段的大小減半。通常使用十六進制編碼來規避字符編碼問題。您也可以使用Base-64編碼，而不是使用base-16（十六進制）編碼;您也可以使用Base-64編碼，而不是Base-16（十六進制）編碼。它將使用每個字符6位而不是4位，並且僅相對於blob 4：3增加存儲量，而不是在十六進制字符串的情況下增加2倍。

來源

2015-11-01 20:23:18 Kenney

在我的第一次測試中，數據庫的大小增加了33％。我認爲這可能是我的錯。當我輸入數據時，我告訴它輸出字符的限制是32.也許這會在轉換後引起一些額外的絨毛？當我看看錶，現在我看到0xDFCF28D0734569A6A693BC8194DE62BF00000000000000000000000000000000，而不是僅僅DFCF28D0734569A6A693BC8194DE62BF –

我還要提到的是我的編碼DFCF28D0734569A6A693BC8194DE62BF爲基本-64字符串，它變得比32個字符。 –

你首先*解碼它，當然，所以它變成了16個字節。然後編碼它，它會變成21到22個字符。對Base64進行編碼將總是增加大約33％的大小，並且對Base16的編碼將總是將大小加倍（增加100％）。 – Kenney

如果您使用varchar或nvarchar來存儲字符串0-9和A-F，那麼您應該真的使用varbinary類型。每對十六進制字符代表一個字節，所以varbinary每個字節的數據在磁盤上需要1個字節，其中varchar每個字節的數據需要磁盤上的2個字節，而nvarchar每個字節的數據需要磁盤上的4個字節。

有varbinary而不是varchar會減少數據庫的整體大小，並且會加快查詢速度，因爲需要從磁盤讀取更少的字節。

來源

2015-11-02 00:25:51

十六進制值只是數字，所以你可能會更好地存儲它們。例如123abc可以很好地轉換爲1194684，並且只需要4個字節而不是8個字節（6個字符+ 2個字節varchar開銷）。所以提供的號碼不會超過2147483647，你可以將它們全部存儲爲int。

但是，如果你想列限制爲僅包含值0-9和a-f，那麼你可以使用一個check constraint，是這樣的：

ALTER TABLE YourTable 
    ADD CONSTRAINT CK_YourTable_YourColumn CHECK (YourColumn NOT LIKE '%[^0-9a-z]%')

來源

2015-11-02 00:42:33 DavidG

所以我希望這可以工作...並決定嘗試將十六進制測試爲十進制，並發現即使是一半的字符（16）也等於超過16個字符的數字並超過2147483647.因此，這可能會失敗或增加我認爲的大小。 –

那麼你可以使用'bigint'而不是'int'，它一直到9,223,372,036,854,775,807並且是8個字節。 – DavidG

我可以限制SQL Server列中的特定字符嗎？它會提高大小和查詢速度嗎？

回答

相關問題