如何提高数据库建模型的能力

[cs5117155]

虽然我已经工作 3.4 年,但是我在设计数据库建表的时候，总会在写代码写到一半的时候，才发现自已当时设计表有问题,还需要重新调整,数据表结构变，代码又要变了.这样效率太低了。

比如建立一个商城分销,最基本的用户表,分拥表,资金变动表,统计表,商品表,订单表，退款表，商户表...等。 一开始的正常逻辑，用户下单购买 50 元的商品，付款后，过了 7 天后自动收货,确认已经完成。然后开始奖励下级的代理与店铺分拥。

但是过了半年后,经过资本家的密谋,说要把逻辑修改一下,用户下单后，代理不能看到 50 元的订单,把订单随机修改为了<=50 元，目的不让代理分拥太多。必要时刻干脆把订单隐藏了，让代理没有这个订单。说白了就是要在商城里面添加暗操作。还有等等的骚操作。

所以现在如果修改代码,就涉及很多表要修改了，工程量也多。我该如何避免设计之后的表无法满足后续的迭代升级，有专门设计建模型的书籍推荐看看吗

[leonme]

我理解需求变更导致表结构变更是正常的，但还是同求工作 10 年以上大佬指点指点

[ChoateYao]

这就是软件开发的痛点，你永远不会知道下个需求要做什么。

就好比本来用户名是唯一的，一段时间过后用户名允许重复，这种需求你永远没有办法预估。

[shanghai1943]

依个人浅薄意见，关于扩展性这些东西是能想到的就尽量先想到，想不到的就不强求，先满足当下功能最重要，毕竟往后的需求变动了，需要改成啥样并不知道，假如现在提前铺好了扩展性，但是往后需要改的不是这个样子，有可能就是白费劲了，所以满足当下是第一优先。

[linbiaye]

这个没有办法，新需求和以前的逻辑，设计冲突太正常了。

[DeWjjj]

我的做法是旧表迁移新表 字段不重复利用。
相当于订单不重复，或者订单需要改形式。旧订单号原地不动，全部迁移到新订单上。

[statement]

扩展是未知的。但好的设计。肯定是易扩展的 开始不过度设计 但扩展性要高

[levelworm]

需求变更的确没办法，除非你能猜到老板将来的想法。而且这个未必需要数据库变更。

[saulshao]

没有任何办法能解决你提到的问题，什么叫变更？变更就是你之前无法预料，当它要发生你才知道。