程序设计,功能更新很快,旧的设计跟不上了。

我现在接手一个项目,属于商城性质的,功能有:购买各种游戏卡,手机充值卡,进行移动联通手机固话的直充,销售彩票,销售火车票,其中游戏卡,手机充值卡的这些卡的卡号密码信息在我们自己的数据库中有对应的表,手机固话的直充,彩票,火车票这些需要与各种第三方平台交互,来获取对应的信息,或者直接进行充值。

这个项目的订单这块设计是:
产品表(现有个各种产品的信息),
产品类别表,
订单表,
明细表(最初是针对销售游戏卡,手机充值卡进行设计的,应该没有想过现在会有许多的新功能),
明细辅助表(后加的,用来存放明细表存放不下的信息,如:火车票信息很多)
本地库存表(用来存储游戏卡,手机充值卡的卡号密码信息),

由于现在新增加了许多新的功能,现在的明细表根本不适合存储彩票,火车票这些信息,以前的开发人员勉强的把这些的信息都塞进了明细表,有些多余的字段放不下的才建了一个明细辅助表,把存不下的信息放在这里。

新产品的许多字段都不相同的:
像彩票会有号码,福彩发送过来的各种的订单号,机器号,还有用户的手机号。
火车票会员车次,时间,起始站,终点站,铺位的各种信息等等。
手机空充会有手机号,充值金额,余额等信息。

现在的疑问是有这么多的不同类型的产品,属性信息相差很大,只使用一个明细表可以吗?如果再加新的功能(商务现在又在谈新的功能了),现在应该怎么改进一下呢?

如果重新设计这块,应该怎么做呢?

不知道自己是否描述清楚了,还请各位指点一二。。。

2011年02月16日 15:48 "hechenhui1983"的内容
现在的疑问是有这么多的不同类型的产品,属性信息相差很大,只使用一个明细表可以吗? ...

这个好像属于需求这块吧,你要和客户商量,来确定需求目标应该是一个什么样的更合理。

这个项目是公司自己的,最初只要游戏卡的销售,后来陆续新增了许多不同类型的产品
并且内容相差很大,每次接手的人员又把信息存入明细表中。

举个例子:
明细表中的卡号,密码字段最初是存放游戏卡的卡号密码信息的。
新增彩票销售后,这里存放的是彩票的票号,彩票平台的订单号。
新增火车票销售后,存放的是出发站-到达站,始发站-终点站的信息。

最初设计的字段完全变了性质了,要靠后来的开发人员对照着文档和程序来猜测现在字段的
意思了,应该怎么设计才能避免这种情况??

下个月又要开发新的功能了,相关的内容更多,我应该怎么做会好一些???

面向表思维就是辛苦,也痛苦你了。

不知道你肯不肯大换血而已。不过你暂且可以把一个实体类看作一个表来理解。

“不同类型的产品”,请回想一下“类”是指什么。如果不是表思维,很容易就想到建立不同的类。注意“产品的不同类型”与“不同类型的产品”核心是不同的。“产品的不同类型”关注的是“类型”,其并不是实体,没有唯一标识,同时“产品”没有定语,也就说明所有东西视同一样,像入货一样,所有东西视为“入的货”,于是属性上只会存在与“入货”相关的字段,如“入货时间”、“批次”、“入货的类型”等,而货的另外一个身份不需要关注。“不同类型的产品”关注的是“产品”,不同类型的产品,所以单项关注的是“某类型”的产品,所以产品的各项属性需要明细,刚好与前者相反。

对应的表思维,个人感觉应该如下:
关注类型:
[card]
id、type、info
1 、游戏、xxxx
2 、机充、xxxx

关注实体:
[gamecard]
id、number、某游戏
1 、123456、XXXXXX
[phonecard]
id、number、服务商
1 、345678、XXXXXX


其实只要定义好角色,那么其相关属性就会被确定,属性对角色来说是存在意义的。就算“类型”这个属性,也要看定语——是card类型,是游戏卡类型,还是充值卡类型,千万别取巧。



[该贴被SpeedVan于2011-02-17 13:34修改过]