將基於收入的數據集儲存在關係數據庫中

我有幾個基於收入的數據集，結構如下：

Subject                 2012   2013    2014    2015
online marketing         54      50     60      80
website ads             900     850    320     250
mobile ads               60      80    120     130       
video ads                30      40     50      80

有超過 10 個表（例如：website_1 / website_2 / website_3）。我打算將數據集更改為以下結構，以便我可以加入表格並根據年份比較數據。

Subject                 revenue   year 
online marketing        54        2012 
online marketing        50        2013
online marketing        60        2014
online marketing        80        2015 
website ads             900       2012
....             
mobile ads              60        2012 
....             
video ads 
...      

我不認為上述結構是有效的。將此類數據儲存在關係數據庫中的最佳方法是什麼？

為什麼你認為第二種設計效率不高？這將是我向您推薦的設計。它允許擴展數據集以添加更多主題和更多年份，而無需調整架構。

要擴展規範化，請將主題放在他們自己的表中並從主表中引用它。這將減少主表中的重複名稱，並減少儲存數據所需的空間。

根據您是否可以，您還可以通過在主表中添加一個名為 的列來將表計數減少到 3 website，然後創建一個新表來保存網站列表並從主表中再次引用它。

然後你會得到一個類似於這樣的結構：

create table "websites"
(
 id int not null primary key,
 name varcher(64) not null unique
);
create table "subjects"
(
 id int not null primary key,
 name varcher(100) not null unique
);
create table "revenue"
(
 id int not null primary key,
 website int not null,
 subject int not null,
 year smallint not null,
 value int not null,
 constraint uk_revenue unique (website, subject, year),
 constraint fk_revenue_website foreign key (website) references website (id),
 constraint fk_revenue_subject foreign key (subject) references subject (id)
);

這會為website、subjects和的創建一個表revenue。該revenue表包含對前表的引用，並且還創建了一個unique constraint跨越 , 和 的組合，website以防止重複條目。subject``year

自然，規範化使查詢定義更大（因為您現在需要連接到其他表），但這實際上是微不足道的，並且在我看來，輕鬆擴展到多個網站、主題和年份的能力值得付出額外的努力來編寫更長的查詢.

隨著時間的推移，如果數據集增長到查詢變得非常緩慢的程度，您可以歸檔不再需要的數據，或者以非規範化的方式對其進行儲存。

引用自：https://dba.stackexchange.com/questions/129486