Excel记录和数据库设计一个思维上的区别
本帖最后由 Jack.Cheng 于 2023-8-25 13:55 编辑工作中经常听到很多客户是在用Excel记录日常业务数据，现在想要用活字格做B/S系统，来迁移到线上。Excel这种方式特点是又能存储数据又能读取数据，配合VBA还可以实现业务逻辑；B/S系统发展到现在，数据库、业务逻辑和用户界面都分层了，所以对于很多熟悉Excel的人员，把之前的业务数据迁移到数据库里面，一个很大的坎就是数据库结构设计，这里不是简单的把Excel的列转成表字段即可，里面需要做业务逻辑分析，根据三范式设计出合理的，可维护的表结构。这里的门道挺多，这个帖子也无意与赘述这里的方法论，就谈一个思维上的小点，希望看到的人能有启发。
讲两个实际的场景。
第一个是关于设备管理的，需要记录每月的正常次数和异常次数，用Excel大家很自然会想到这样子来做
但是如果原模原样迁移到数据库的表里面，就会存在这样子一个问题：
如果我要做一个饼图来看具体月份正常和异常的占比，以目前的表结构就不是很方便了，因为需要先做SQL列转行操作
SELECT
"日期" 日期,
'正常' as 状态,
"正常" as 数值
FROM
"表1" UNION
SELECT
"日期" 日期,
'异常' as 状态,
"异常" as 数值
FROM
"表1"然后用活字格的图表功能，开发一个饼图
所以对于这种Excel存储方式，我们需要把数据库表这么设计
是不是做后续业务就方便一些了呢？
第二个场景是生产线上有个产品生产出来以后有多个质量问题，比如说问题a问题b问题c问题d，对于A1产品只有问题a和问题b。那么按照传统Excel的思路会这么做表
如果原模原样迁移到数据库的表，要统计一个问题下之前有哪些产品出现过来形成报表，是不是又得SQL列转行了呢？
数据库可以这么设计：
那么后面查看产品的问题，和查看发送过问题的产品，是不是就好做很多了呢？
页:
[1]