2017-06-05 81 views
0

我有許多表格完全鏡像Excel工作表。Excel遷移到數據庫設計

例如

Excel中

Region Year Jan  Feb  Mar  Apr  May  Jun  July Aug  Sep  Oct  Nov  Dec 
North 2008 100  200  400  600  800  900  180  290  720  900  400  120 
South 2008 100  300  600  900  899  900  300  900  300  900  100  200 
... 

我寧願不存儲在數據庫中的上述excel工作表。

但人們問我爲什麼?

爲什麼不像Excel那樣存儲它,因爲行數會更少,性能更快?

我如何說服存儲更少的列是更好的設計?

像下面這樣:

我使用許多RDBMS喜歡的Sybase,甲骨文,SQL服務器,MySQL的

Region Year Month Profit 
North 2008 Jan  100 
South 2008 Jan  100. 
North 2008 Feb  200 
South 2008 Mar  400 
... 

我覺得上面的設計是優雅的,這就是我所看到的每一個其他地方我一直在,但在我目前任務中的人們希望桌子能夠像Excel一樣。

我該如何說服他們將Excel設計鏡像到數據庫中是一個壞主意?

回答

0

我想知道誰會輸入/修改/查詢數據,以及他們將如何執行這些操作(例如,編寫實際的SQL,使用Excel作爲前端,以及其他一些填充黑色應用程序等)。

如果用戶將會編寫任何SQL,我猜你會更容易在關係模型上銷售它們,這取決於他們需要做多少編碼。舉例來說,一種搜索個月,其中利潤> 350:

-- excel-like structure 

select Region, Year, 'Jan' as Month, Jan as Profit from excel_table where Jan > 350 
union all 
select Region, Year, 'Feb' as Month, Feb as Profit from excel_table where Feb > 350 
union all 
select Region, Year, 'Mar' as Month, Mar as Profit from excel_table where Mar > 350 
union all 
... and on and on and on and on ... 

-- relational structure 

select Region, Year, Month, Profit 
from relation_table 
where Profit > 350 

爲excel_table另一個乏味例如:添加每個月新的利潤值(如可用)。

一旦你讓他們習慣於用每個月的獨立where子句寫很多查詢,你可以指出如果你沒有每個'month'列的索引,性能可能會下降,這反過來可能意味着更多的數據庫空間使用,數據緩存空間可能更少,並且可能需要更長的時間來插入/更新/刪除數據(由於更新了更多索引)。


關係模型的一個缺點當然是數據的顯示看起來像excel電子表格。

如果用戶將編寫自己的代碼,那麼他們將不得不跳過一些環節來構建數據透視表(即將月/利潤行轉換爲列)。

然後,如果他們的前端/應用程序可以爲他們處理這個問題,那麼這可能不會有太大的問題...?