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，Oracle，SQL Server，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，我猜你会根据他们需要做多少编码来更容易地在关系模型上销售它们。例如，搜索Profit＆gt;的月份。 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子句编写大量查询，你可以指出如果你没有每个'月'列的索引可以降低性能，这反过来可能意味着更多数据库空间使用量，数据缓存空间可能较小，插入/更新/删除数据的时间可能更长（由于更新了更多索引）。

关系模型的一个缺点当然是将数据显示为excel电子表格。

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

然后，如果他们的前端/应用程序可以为他们处理这个问题，这可能不是一个问题......？

Excel迁移到数据库设计

1 个答案: