我来征集一些关于系统部分的设计意见
目前有个关于机票销售系统的有一个需求是这样的：

  机票代理商可以在系统上销售机票，每个代理商销售的机票可能只限定在某个城市，比如，A代理商只能销售从成都出发的机票，而B代理商可以销售全国各大城市出发的机票。
  
原来的设计是 
1.将 全国的城市以代码表的形式存在一张city表中，其中有字段 CityId（序列）,cityCode（城市代码）,cityName（城市名）
2.每个代理商有一个可以出票的城市列表，都放在ticket_city表中，有字段id,cityId(外键city表),代理商ID（外键代理商表） ，这里可以表示代理商有多个出票城市

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

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

------解决方案--------------------
从多对多的角度来考虑,貌似只能这样了!
------解决方案--------------------

探讨

从多对多的角度来考虑,貌似只能这样了!

------解决方案--------------------
关注下．．．．．．．．．．．．．．．．．．．
------解决方案--------------------
!markit![b][/b][b][/b][b][/b][b][/b][b][/b][b][/b][b][/b][b][/b][b][/b]
------解决方案--------------------
如果在表的设计中简单了，那么在业务处就复杂了
判断代理商经营的城市特点，如国基本都能代理，那么表中只存不能代理的城市，反之，则只存能代理的城市，加一个字段，区分库中存的是能代理的城市还是不能代理的城市
这样表结构简单了，不过在业务处理上就复杂了，要进行判断、筛选
PS:不是很了解你的业务，不知道说的对不对，就当胡侃了....哈哈
------解决方案--------------------
1. CityId（序列）, CityCode（城市代码）好像重复了，CityCode 做主键就行。
2. 建一个城市分组表，groupid,groupname,cityids（成员城市id列表）。
3. ticket_city 表加一个字段，groupid（外键），cityid 和 groupid 二选一存储，如果有 cityid 则忽略 groupid。
业务逻辑会稍复杂点，但存储数据量能少点。怎么取舍就看需求了。