banq大哥好，大家好，第一次发帖，假如有个联通的项目，其中一个功能，让用户能查询当前联通旗下所有类型“卡”（比如小灵通，乡镇卡之类）的付费标准及与卡相关服务项目，但是问题来了，最近联通在年前新增一个卡类型，如意卡，有它的自己的付费标准，可能还有期限要求，如它要求过了3月31日又是另一个付费标准了！其实现在我们做项目很多时候都没有预见性，下面是我个人的尝试方案，请bang大哥和大家不吝赐教：
1。建立一个卡类型管理画面，把所以信息保存到数据库，即使将来还有新卡类型也只是增加记录，但是banq大哥好象很不主张以数据库为基准的设计，呵
2。在项目中编写卡的接口或者是抽象类，将来有了新卡类型用反射获取相关信息
但个人觉得有点麻烦，是不是将来联通新增一个卡类型，就又要我们开发公司帮忙开发一个新的子类插入系统中，虽然可能不需要重新编译整个项目，但是还是觉得不方便，是不是我认识有误，用反射做开发不是这样的？
设计的好处就在于使用的方便、维护的方便
做设计的时候要做成本的分析，怎样避免最困难的事情
跟用不用数据库没有任何的关系
如果方法一的维护成本低于方法二的维护成本就应该选择方法一
反之亦然。
没有绝对的设计，也没有一成不变完美的设计
用户需求的变化是必然的
但是如果你做软件的时候始终站在用户的角度而不是自己的角度
设计起来就得心应手了
card(ID，卡名....)
资费(ID,fk_cardid,起始日期,结束日期,收费标准....)
card 1--------->n 资费
谢谢Coolyu0916 的回复，明白你的意思，想问清楚一下，假如你在项目中遇到我说到情况，你一般怎么设计呢，具体一点，先谢了！
因为没有了解你的整个的架构所以只能简单说一下
不知道是不是需求只是你说的那一点，还是已经有了现有框架需要增加这个功能
如果有了现有的框架，那么你基本不需要想什么，添上代码就好了
如果是自己新建的，那我就想问问你要查这些卡，目的是什么？？
为了展示？？为了计费？？还是只是一个中间变量类型？？
如果查询是最终目的，可以设计的很简单，三层结构访问就可以了
计费的话2层结构就够了，一个简单的软件就可以了
如果是中间变量类型那就需要重新定位它在系统中的位置了。
>是不是将来联通新增一个卡类型，就又要我们开发公司帮忙开发一个新的子类插入系统中,虽然可能不需要重新编译整个项目，但是还是觉得不方便
我个人认为是这样，业务模型变化，必然带来代码更新，不能幻想机器人帮助我们来完成业务代码。象你试图通过数据库记录变化，替代业务变化，这可能在一定情况下有效，但只能是一个临时之计，业务代码也会要修改的。
我们可以通过好的设计降低代码更新量，比如四色模型设计中，我们可以设计一个卡类，用来描述卡的一般属性通用特性，概时，需求变化时，只要实现特殊部分就可以，比如如意卡的特殊之处，围绕特殊之处实现一些功能添加修改。
采取OO，只是比以前更快更方便应对需求变化，而且，不会担心一旦修改，牵一动百的影响，系统只是比以前健壮。
如果还希望更快，通过MDA这些工具，UML图改了，代码就出来了...当然目前不是非常成熟。
谢谢banq大哥的指点啊，我自己也感觉数据库上一定修改不能从根本上解决问题，可能以前做的一些项目都是从数据库为起点的开发，所以最自然的往那方面去想，但是看了banq大哥的“数据库时代的终结”一文，感觉设计思路上开阔很多！谢谢，另外banq能具体帮我讲讲你说的四色模型设计吗？以前没有接触过这个概念，自己学习中..
我也很想知道什么是四色模型设计
也想知道怎么不通过编译源代码和数据库怎么加入新的卡类型
希望banq不吝赐教
详细说明
四色原型:
http://www.jdon.com/mda/archetypes.html
四色原型一般在MDA中起初使用，是对需求的一种科学分析方法。
它与领域模型区别是：
Evans DDD是一种MDD，比MDA/DSL/DSM自动化程度差一步，是现今我们普遍采取的方式。四色原型比领域模型更抽象，原始。
刚刚将四色原型看了一遍
受益匪浅
不过有一些不明白的地方
比如说你需要添加一种新的role
如何动态的添加而不需要编译源代码或者添加数据？？