目前我的系統規劃中, 有 300 個 小 Table, 主要是用來存放(代碼,名稱)用的 , 代碼長度不同, 每個 Table 的筆數小於100, 這樣子Table 的數目 會影響 databse 的效能嗎 ? 需不需要合併成一個 ? 但是合併後, Table與Table間的一致性,就無法用 databse server 控制, 這該如何處理呢 ? ****阿彌陀佛*****

基本上我覺得是你的資料結構設定錯誤，不清楚你的CASE內容， 不過我是覺得應該是你的資料結構有問題，頂多設計個二個至三個table 就可解決你的問題了，不需那樣數百個table。 你先往你的資料庫正規化這個方向去處理吧.

我也有想過用一個 id Table 去存放所有的代碼, 再用一個欄位區分 例如 IdKind varchar(10) MyId varchar(10) MyName varchar(50) Myremark varhcar(100) 備註 你的意思是這樣嗎 ? ****阿彌陀佛*****

你的題目不清不處，我實際上不是很清楚你到底要做什麼， 不過大概就是你講的那樣子，每個table改用一筆資料去取代就夠了， 每個table變成一個 ID數值，如果這個table又內含 數10~100筆資料， 就把這些資料全部放在同一個table 就夠了, 也就是關聯式資料庫的概念而已.

只是這樣就喪失 reference case 的功能, ex: ALTER TABLE idvipitem ADD CONSTRAINT fk_idvipitem_idCost FOREIGN KEY (cCostId) REFERENCES idCost (cCostId) ON UPDATE CASCADE; 當我改了 idCost.cCostId 時, 資料庫會幫我自動修改 idVipItem.cCostId ****阿彌陀佛*****

... 發表人 - P.D. 於 2004/12/17 12:55:35

引言: 目前我的系統規劃中, 有 300 個 小 Table, 主要是用來存放(代碼,名稱)用的 , 代碼長度不同, 每個 Table 的筆數小於100, 這樣子Table 的數目 會影響 databse 的效能嗎 ? 需不需要合併成一個 ? 但是合併後, Table與Table間的一致性,就無法用 databse server 控制, 這該如何處理呢 ? ****阿彌陀佛*****

合併後無法處理table與table的一致性, 我想這是程式上的寫法及技巧可以 解決的, 要注意的是-開1個10000的table及開100個100筆的table, 這兩者 當中雖然都是開啟等量的資料, 但是否所佔用的效能與資源就會一致呢? 其實不然, 後者所耗掉的系統資源遠要大於前者, 因為一個table要被開啟 不是單純的open就完成的, 還有前置的sql解析, buffer運用, connection行為, 記錄篩選, 資料回傳, 最後才open, 換句話說, 開100個table, 就要重覆100次 這樣的行為模式, 如果設計上又是多人連線, 則再加上分享機制, 鎖定機制等等 那這樣應該夠你判斷是該用300個table 還是合併, 這並沒有一定的原則, 端看 你真正的用途! 不過說真的, 300個也太多了, 萬一其中一個crash, 維護及除錯 都是很難的, 不是嗎?

這些小 Table 大約僅止於有2個 Field (Id varchar(10), Name varchar(10) ) 主要是顯示而已, 主要考量點有 1.寫程式的觀點 合併:只要寫一個Table就好了,單是修改代碼時要注意哪些 Table 有用到此 代碼 分開:要維護300個 Table, 修改代碼時不用特別管理 2.資料庫的一致性 合併:無法用資料庫的一致性來自動維護 分開:資料庫設定好, 修改代碼時不用擔心 3.系統 Crash 影響 合併: 分開: 因為是後端資料庫, 如果 crash, 很難評估 4.資料庫效能 這點不知道 database server 是如何設計的, 猜測像 BDE 一樣, 有一個 MaxFileHandle, 如果 Table 的數目多, MaxFileHandle 要調高一點, RAM 就可能吃多一點, 這一點應該是合併會優於分開 不知是否還有未考慮的因素 ? ****阿彌陀佛*****

因為沒有完整去瞭解你的架構, 所以基本上很難理解你的想法, 不過就如我提 到的, 分開與合併並沒有一定的準則, 而我們也沒有辦法可以付諸那麼多的心力 去研究, 只要你自己能掌握就好! 不過對我們來說, 如果要寫一個大型專案的話, 那麼龐大的資料表不是一個專案很好的規劃, 因為專案一旦交付給使用者管理後, 使用人未必有能力應付各種資料表的狀況, 另外上面也提到合併後的關聯性問 題不是不能解決, 端看程式如何下法, 以上提供你參考~~~ 註: 你提到"我的系統中小 Table 很多, 會不會影響庫效能 ? ", 或許也代表你或多或少會有疑慮, 即有疑慮不妨採取另類思考, 然後自己進行多種狀況測試, 也許 可以得到一些數據供你佐證 發表人 - P.D. 於 2004/12/18 03:30:45

回答在--------底下 這些小 Table 大約僅止於有2個 Field (Id varchar(10), Name varchar(10) ) 主要是顯示而已, 主要考量點有 1.寫程式的觀點 合併:只要寫一個Table就好了,單是修改代碼時要注意哪些 Table 有用到此 代碼 分開:要維護300個 Table, 修改代碼時不用特別管理 ------------------------------------------------ 合併你也只要寫一個畫面就好，有一個分類可以讓User選，或者 選單進入點不同進入不同分類。 分開300個的話同一個畫面不同選單進入點切換不同SQL語法(對應不同Table) 我的經驗是，你要分清楚這300中有哪幾個是屬於哪個子系統的，亦或者這合併Table應該歸屬全系統層級。 2.資料庫的一致性 合併:無法用資料庫的一致性來自動維護 分開:資料庫設定好, 修改代碼時不用擔心 ------------------------------------------------- 合併就只要修改一個Table就好了啊..U_U||| 分開光是對Table..天啊..300個..然後又幾乎都是相同結構.. 寫300個名稱會寫到沒力.. 3.系統 Crash 影響 合併: 分開: 因為是後端資料庫, 如果 crash, 很難評估 ------------------------------------------------- 合併：會死粉難看，系統的Table掛了會影響整個系統。 分開：各子系統仍可以獨立運作。 4.資料庫效能 這點不知道 database server 是如何設計的, 猜測像 BDE 一樣, 有一個 MaxFileHandle, 如果 Table 的數目多, MaxFileHandle 要調高一點, RAM 就可能吃多一點, 這一點應該是合併會優於分開 ------------------------------------------------ 如果一個Table裡有100萬筆資料，選取資料那效能會變很低(MSSQL)， Oracle還好。Access等檔案型的最差。 以我的客戶經驗，過了一年之後必須幫客戶拆Table或者資料庫。 以一年份為個間斷點。

要看具體情況, 一般不會有什麼影響的 aol:delphisunlight