我现在接手一个项目，属于商城性质的，功能有：购买各种游戏卡，手机充值卡，进行移动联通手机固话的直充，销售彩票，销售火车票，其中游戏卡，手机充值卡的这些卡的卡号密码信息在我们自己的数据库中有对应的表，手机固话的直充，彩票，火车票这些需要使用socket与各种第三方平台交互，来获取对应的信息，或者直接进行充值。
这个项目的订单这块设计是：
产品表(现有个各种产品的信息)，
产品类别表，
订单表，
明细表(最初是针对销售游戏卡，手机充值卡进行设计的，没有想过现在会有许多的新功能),
本地库存表(用来存储游戏卡,手机充值卡的卡号密码信息),
明细辅助表(后加的，用来存放明细表存放不下的信息)
由于现在新增加了许多新的功能，现在的明细表根本不适合存储彩票，火车票这些信息，以前的开发人员勉强的把这些的信息都塞进了明细表，有些多余的字段放不下的有建了一个明细辅助表，把存不下的信息放在这里。
我现在的疑问是有这么多的不同类型的产品，属性信息相差很大，只使用一个明细表可以吗？如果再加新的功能(商务现在又在谈新的项目了)，我现在应该怎么改进一下呢？
如果重新设计这块，应该怎么做呢？（打算自己有时间时，作为练习）
不知道自己是否描述清楚了，还请各位指点一二。。。。
方法一:一个订单表，N个明细表，不同的商品对应不同的明细表这样设计更明了，也更面向对象
相当创建对象订单，在创建一个继承对象订单的彩票订单，类似这种
方法二：
创建N个订单表，没有明细表，不同商品对应不同订单表
比如彩票订单一张表，火车票订单一张票
采用那种情况具体看开发了，
如果数据量大的话可以用方法二，更方便分表
方法一的开发成本更低一下
订单明细表乱 是因为设计的问题，明细表里面应该只需要有 商品 和数量 等公用的其他没用的放到商品表里
纵表！
有两个解决方案：1.要是大部分的属性都是通用的 你可以中半纵半横
2.属性基本上都是不一样的，那你就彻底用纵表
虽然在性能上有点小慢 但是总是一个解决方案呀！电信项目中就是一个典型的例子！
要是还是不懂得话可以加我腾x号 昵称吧！jeasy.记住后面还有个点呢！