SQL 行转列的一些思考

对于关系型数据库来说,表的设计总是不能满足所有要求。满足了事务性就不能满足分析性。比如最常见的学生,课程和成绩的关系,这是一个矩阵的关系,学生是行,课程是列,成绩就填在他们交叉的地方:

 语文数学
尼玛10020
铁锤10099

一般我们设计关系型数据库的表会把这种关系设计成三张表,学生表,课程表和成绩表。成绩表中分别有学生表和课程表的外键。另外一种设计的方式就是设计成上面的表格的样子,课程作为成绩表的列。这两种方式中,第二种方式更满足分析性需求。但是往往我们设计中会使用第一种方式,因为已经存在学生表和课程表,成绩表必然要保存和其它两张表的关系-外键,这样更能满足事务性。

如果项目本身就是分析性大于事务性的,那一开始的设计就会把数据库设计成分析性的。但是如果一开始是设计成事务性的,我们必然也有需求做一些分析性的工作-单纯事务性的项目比较少。那这种时候我们就需要把这种事务性的表向分析性做一些转化。view可以很好的起到这个作用,既不用重新建表,又可以建立新的表结构。view都是建来做查询的,所以view的创建一定要考虑很好的满足分析性。

把第一种方式的表结构通过行转列的方式转化成第二种方式的表结构。

SELECT name,

max(case subject when '语文' then score else 0) 语文,

max(case subject when '数学' then score else 0) 数学

FROM student_score;


把表结构转化成利于query的view在性能上肯定不如直接建表,但是对于数据较少的应用应该也足够了。

以上仅仅是个人浅见。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值