Excel迁移到数据库设计

Question

我有许多表格完全镜像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设计镜像到数据库中是一个坏主意？

Answer 1

我想知道谁会输入/修改/查询数据，以及他们将如何执行这些操作（例如，编写实际的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电子表格。

如果用户将编写自己的代码，那么他们将不得不跳过一些环节来构建数据透视表（即将月/利润行转换为列）。

然后，如果他们的前端/应用程序可以为他们处理这个问题，那么这可能不会有太大的问题...？