我有一個問題,在一個更快,更好和未來的T-SQL設置?查詢表vs進入表
是更容易與ID和狀態條目的查找表,以便
ID | Status
-------------
01 | Success
02 | Failure
03 | Processing
抑或是最好只進入狀態值在每行?
這種效果是如何寫入查詢的?使用查找表而不是僅僅將行狀態輸入到行中是否是良好的關係數據庫設計?一個比另一個快嗎?
我覺得查找表是要走的路,但我在某些數據庫中看不到那麼多。
我有一個問題,在一個更快,更好和未來的T-SQL設置?查詢表vs進入表
是更容易與ID和狀態條目的查找表,以便
ID | Status
-------------
01 | Success
02 | Failure
03 | Processing
抑或是最好只進入狀態值在每行?
這種效果是如何寫入查詢的?使用查找表而不是僅僅將行狀態輸入到行中是否是良好的關係數據庫設計?一個比另一個快嗎?
我覺得查找表是要走的路,但我在某些數據庫中看不到那麼多。
我個人會爲這些項目使用單獨的狀態表。然後,您將在主表和獨立狀態表之間使用外鍵。就查詢而言,您只需使用JOIN
即可包含實際狀態名稱。
SELECT *
FROM yourTable t
LEFT JOIN yourStatus s
t.sid = s.id
我覺得它允許更多的靈活性,在事件的狀態名稱更改只更改的值在不同的表,而不是對你的主表執行UPDATE
。
你的表結構可能與此類似:
MainTable
id int PK,
sid int FK - to status table
col3,
col4...
Status Table
id int PK -
name varchar(50)
IsActive bit
我認爲擁有ID並將其用作表中的外鍵總是更好。我認爲這是最有前途的證明解決方案。對於這種情況,特別是如果你想按狀態過濾,它可以加速思考,因爲它不會比較字符串。
此外,您可以將此狀態表用於數據庫中的其他表,並且交叉數據更容易。
而且索引更容易。
所以在我看來,我認爲這是要走的路。
乾杯
就個人而言,我使用狀態表,但主鍵是不是一個整數,而是一個varchar(6)。這使得運行臨時報告變得容易,同時確保狀態字段不是自由格式。
我的狀態表一般有以下字段:
create table foo_status (
status varchar(6) primary key,
active bit,
name nvarchar(255),
description ntext null
);
和數據表引用它通過一個外鍵
create table foo (
...
status varchar(6) foreign key references foo_status(status)
...
);
create clustered index foo_fk_status_index on foo(status);
沒有更好的辦法來做到這一點。這取決於您的業務邏輯和您正在存儲的數據量。
通常建議使用鎖定表,因爲您避免了重複的數據,並且如果您只想加載狀態值(無需重新設置),它會更快。想象一下,你想用狀態值創建一個下拉菜單。你一定要做出
select * from lockup_table.
那麼你一定要與狀態處理
SELECT *FROM table t
LEFT JOIN lockup_table lt ON t.sid = lt.id
WHERE lt.status LIKE 'Processing'
它會選擇行仍然快過,因爲你的SGBD將使用PK索引的能力。
但有時候最好有重複數據,避免連接操作。如果您不知道連接操作需要一段時間,則應該嘗試刪除鎖定表並查看您的性能是否隨此更改而改進。您也可以爲該列創建一個索引。它會提高性能。
結論,如果你想要一個帶有靜態值(Success,Processing,Failure)的狀態列,你不需要一個鎖定表。但是,如果您想要使用動態值的無限值範圍,以便明天可以添加更多狀態值等,則應該創建一個鎖定表。
我還想指出,在某些情況下,這些狀態將永遠不會用在我知道的另一個表格中,而且我不確定它們多久會發生變化。 – MattB 2012-08-06 13:54:05
在這種情況下,只需在表格中添加一個新列。 – j0N45 2012-08-06 13:56:34
「失敗」狀態是否會因其它命名而改變,或者它是否意味着其他內容? – 2012-08-06 13:58:08