Excel记录和数据库设计一个思维上的区别

工作中经常听到很多客户是在用Excel记录日常业务数据，现在想要用活字格做B/S系统，来迁移到线上。Excel这种方式特点是又能存储数据又能读取数据，配合VBA还可以实现业务逻辑；B/S系统发展到现在，数据库、业务逻辑和用户界面都分层了，所以对于很多熟悉Excel的人员，把之前的业务数据迁移到数据库里面，一个很大的坎就是数据库结构设计，这里不是简单的把Excel的列转成表字段即可，里面需要做业务逻辑分析，根据三范式设计出合理的，可维护的表结构。这里的门道挺多，这个帖子也无意与赘述这里的方法论，就谈一个思维上的小点，希望看到的人能有启发。

讲两个实际的场景。

第一个是关于设备管理的，需要记录每月的正常次数和异常次数，用Excel大家很自然会想到这样子来做




但是如果原模原样迁移到数据库的表里面，就会存在这样子一个问题：
如果我要做一个饼图来看具体月份正常和异常的占比，以目前的表结构就不是很方便了，因为需要先做SQL列转行操作

1. SELECT
   
2.         "日期" 日期,
   
3.         '正常' as 状态,
   
4.         "正常" as 数值
   
5. FROM
   
6.         "表1" UNION
   
7. SELECT
   
8.         "日期" 日期,
   
9.         '异常' as 状态,
   
10.         "异常" as 数值
    
11. FROM
    
12.         "表1"

复制代码

然后用活字格的图表功能，开发一个饼图


所以对于这种Excel存储方式，我们需要把数据库表这么设计

是不是做后续业务就方便一些了呢？


第二个场景是生产线上有个产品生产出来以后有多个质量问题，比如说问题a问题b问题c问题d，对于A1产品只有问题a和问题b。那么按照传统Excel的思路会这么做表



如果原模原样迁移到数据库的表，要统计一个问题下之前有哪些产品出现过来形成报表，是不是又得SQL列转行了呢？

数据库可以这么设计：

    那么后面查看产品的问题，和查看发送过问题的产品，是不是就好做很多了呢？