这样的数据库表该怎样设计？

0 0

这样的数据库表该怎样设计？5

现在有一个workflow的系统，里面有一个交易信息表，这个交易信息表总共加起来有大概110列(column)，这个交易信息表里面包含一个订单信息（大概有30个column),交易信息与订单信息的实体关系是一对一，现在需要设计这个交易，有以下三种考虑：

1, 只设计一个交易信息表，里面包含110列（column）
2, 设计成两个表，一个表的交易信息表（80列），另一个订单表（30列），订单表中包含一个交易ID建立一一对应关系
3, 设计成一个表，但是行列转换过来（只有5到6个column的样子），也就是说设计成Attribute_Name和Attribute_Value的形式，这样的话一条交易记录需要插入110条记录。

问题：如果是你你该怎样设计？这样设计的原因是什么？

数据库设计

2012年9月03日 22:56

paobusi_wu
17
0 0 3

2个答案按时间排序按投票排序

0 0

为什么会有这么多，我猜测是有大量重复的字段，比如

商品1，商品2......商品N,这样

如果是这样，我的建议是第三种。

用性能挟持设计，必须得有更好的理由，比如已经发生的事实，或是100%可预见的，等等。
不然的话，解决性能可以有很多方式，这种绝对是错误的。

我见过这样的设计，至少在维护上很要命，要维护的还刚好是我们的队伍。

之前预留了N个字段，后来发现需要增加个，于是

- 数据库表要改。
空间碎片问题，不是简单加一列就好的。

- 相关程序，配置都要改。
原本无关的批处理等等也需要改！

- 虽然这次需求是加一列，但因为非常繁琐，索性多加几列，万一以后呢？

最终，无论DB还是PG臃肿不堪，基本上是一场灾难！

2012年9月04日 09:48

clxy
825
0 3 62

3条评论

0 0

数据量多大，如果不大三者都行；

1, 只设计一个交易信息表，里面包含110列（column）
查询/写入只对一张表操作；比如我只查订单/只查交易则方案2更好；

2, 设计成两个表，一个表的交易信息表（80列），另一个订单表（30列），订单表中包含一个交易ID建立一一对应关系

只查询部分数据的时候好；但插入的表多； 80列还可以再分；

3, 设计成一个表，但是行列转换过来（只有5到6个column的样子），也就是说设计成Attribute_Name和Attribute_Value的形式，这样的话一条交易记录需要插入110条记录。

这个直接摒弃动态表，数据量上来了，性能肯定跟不上；

2012年9月03日 23:43