我来征集一些关于系统部分的设计意见

lovingprince 2008-06-20 03:45:13

目前有个关于机票销售系统的有一个需求是这样的：

机票代理商可以在系统上销售机票，每个代理商销售的机票可能只限定在某个城市，比如，A代理商只能销售从成都出发的机票，而B代理商可以销售全国各大城市出发的机票。

原来的设计是
1.将全国的城市以代码表的形式存在一张city表中，其中有字段 CityId（序列）,cityCode（城市代码）,cityName（城市名）
2.每个代理商有一个可以出票的城市列表，都放在ticket_city表中，有字段id,cityId(外键city表),代理商ID（外键代理商表），这里可以表示代理商有多个出票城市

下面问题来了，如果A代理商可以销售全国的机票，那么ticket_city就会有city一样多的记录，如果B代理商可以销售除杭州之外的所有机票，那么差不多也和city一样多，这样就会造成ticket_city表记录成倍增长。而且对这些代理商进行城市维护也不太方便。请问各位有没有什么好设计方法或者经验可以解决这个问题？

目前正在考虑重新设计这部分，具体设计方案正在研究中，各位有什么好的意见。

...全文

153 13 打赏收藏转发到动态举报

写回复

用AI写文章

13 条回复

切换为时间正序

请发表友善的回复…

发表回复

lovingprince 2008-06-23

打赏
举报

[Quote=引用 12 楼 sagezk 的回复:]
1. CityId（序列）, CityCode（城市代码）好像重复了，CityCode 做主键就行。
2. 建一个城市分组表，groupid,groupname,cityids（成员城市id列表）。
3. ticket_city 表加一个字段，groupid（外键），cityid 和 groupid 二选一存储，如果有 cityid 则忽略 groupid。
业务逻辑会稍复杂点，但存储数据量能少点。怎么取舍就看需求了。
[/Quote]

恩，不错，呵呵，引入组的概念，如果很多代理商都有相同的多个销售城市的话，的确要节省不少存储空间。呵呵。

sagezk 2008-06-23

打赏
举报

1. CityId（序列）, CityCode（城市代码）好像重复了，CityCode 做主键就行。
2. 建一个城市分组表，groupid,groupname,cityids（成员城市id列表）。
3. ticket_city 表加一个字段，groupid（外键），cityid 和 groupid 二选一存储，如果有 cityid 则忽略 groupid。
业务逻辑会稍复杂点，但存储数据量能少点。怎么取舍就看需求了。

lovingprince 2008-06-23

打赏
举报

晕，有分没人要啊。快来给点建议撒，呵呵e

lovingprince 2008-06-20

打赏
举报

[Quote=引用 9 楼 zwgs1985 的回复:]
如果在表的设计中简单了，那么在业务处就复杂了
判断代理商经营的城市特点，如国基本都能代理，那么表中只存不能代理的城市，反之，则只存能代理的城市，加一个字段，区分库中存的是能代理的城市还是不能代理的城市
这样表结构简单了，不过在业务处理上就复杂了，要进行判断、筛选
PS:不是很了解你的业务，不知道说的对不对，就当胡侃了....哈哈
[/Quote]

你的设计方法我也考虑过，其实就是维护一些规则，存少的在里面。这样表中数据倒是少，估计业务处理起来很复杂了就。原来的设计方式按照估计的话，全国大概300个出票城市。使用我们系统的代理商假设每个城市3家，那么就有900家，假设都可以出全国票的话，那么ticket_city就有900*300=27W条记录。这个应该是在未来3-5内封顶的记录数。如果按照添加规则的方式，那么基本上就900条记录就可以搞定，当然业务上处理起来就要进行规则运算。还是得衡量一下啊

zwgs1985 2008-06-20

打赏
举报

如果在表的设计中简单了，那么在业务处就复杂了
判断代理商经营的城市特点，如国基本都能代理，那么表中只存不能代理的城市，反之，则只存能代理的城市，加一个字段，区分库中存的是能代理的城市还是不能代理的城市
这样表结构简单了，不过在业务处理上就复杂了，要进行判断、筛选
PS:不是很了解你的业务，不知道说的对不对，就当胡侃了....哈哈

lovingprince 2008-06-20