SQL 表多還是少好

桌子的質量不是絕對的，有很多限制因素：

1.資料的分布，如果資料均勻分布在各種型別中，那麼就可以有效地分散操作，在一定程度上可以提高檢索速度，但是如果分布不均勻，某一型別的資料很多，遠遠大於其他型別，那麼使用分表就沒有多大意義了， 並且操作仍然會集中在某個表上，這也增加了系統的複雜性。

2.分表只是表面的展示，其實最有效的效能就是物理儲存分離，如果只是簡單地劃分表，但物理IO還是作用在同乙個硬碟上，不會有太大的效能提公升。

3.如果CPU是雙核的，那肯定要比單核CPU分表要好，分表的初衷是資料庫可以用雙線程掃瞄多個硬碟。

4.而且從你的描述來看，子表的關鍵詞也值得考慮，這會極大地影響查詢的效率。 我每天做了400萬條資料，至少需要儲存3個月，所以我按照人才表使用，效果還不錯，但業務會比較複雜，需要考慮。

一開始只能想到這麼多，希望對你有幫助。

表多比較好，雖然在表多的情況下會有更多的關鍵約束，管理起來比較麻煩，但是實現查詢相對簡單方便。

設計資料庫是一門藝術，沒有絕對的好壞，只有合適和不合適。

大桌子的優點：

在編寫程式的地方，它很容易處理。

都是 insert select update delete 同乙個表。

資料庫中的查詢計畫也非常穩定，因為它只有乙個表。

許多小桌子的優點：

故障處理比較容易，如果任何乙個小表出現問題，都不會影響其他小表的執行。

檢索效能可能會更好。

綜上所述，如果有很多小表和字段是相同的，那麼只是某種型別的字段是不同的。

如果您使用的是 SQL Server 或 Oracle Enterprise Edition。

嘗試使用分割槽表的功能。

這樣，就可以獲得大表“易於編寫程式”的優勢。

您還可以獲得許多小表的優勢，即“當乙個分割槽發生故障時，它不會影響其他分割槽”。

但是，分割槽表索引的建立更為特殊。 如果構建不好，會影響效能。

當然，最好根據關係劃分為多個表。

關係型資料庫的優點可以在網際網絡上查詢，不用說，如果在設計資料庫的時候把所有的資訊都放到乙個表裡，會讓應用寫起來很麻煩，而且執行效率低，最後表被打分了。

如果業務邏輯允許，則分開。

檢索表中的資料需要花費太多時間，並且您的情況可以分開，可以分開的東西不應該放在一起。

建議不要分隔超過 3 個表，db2 join 4 表會比 3 個表降低 30% 左右的效率。

這與桌子沒有太大關係，主要是關於關係。

您可以建立乙個觸發器來實現Zao Qing，以SQL Server的語法為例。

create trigger

on a for update

asif exists (select 'true'

from inserted as i

其中 = 王三' and = 50)update a

set = 50

其中 = 李二'

我認為了解一些普通的應用程式就足夠了。

複雜的SQL語句是完全無用的。

你說的有些是真的，有些是錯的。

學習事物是乙個從簡單到複雜的過程。

普通應用程式對於SQL（讀寫資料、儲存過程等）來說是可以的，但是對於大型程式（包括應用程式和網路程式）來說，SQL讀寫資料一般非常複雜，需要考慮很多因素。

那是因為你還沒有接觸過複雜的系統。

盡量如實寫，或者多寫，太多是不可能的，一般標明公積金供款的比例。

需要對應相對繳費基數，例如，收入ABCD四個等級 繳費基數是1 2 3 4 如果你的公積金繳費基數是1，那麼你的收入應該填寫A等，而不是隨便填。

在查詢分析器中使用 SQL 語句：SP help tablename（tablename 是要檢視表結構的表的名稱）。