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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 1242 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

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

订单

代理

修改

分拥

8 条回复 • 2021-07-02 14:31:38 +08:00

leonme

2021-07-01 14:03:24 +08:00 via iPhone

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

ChoateYao

2021-07-01 14:09:53 +08:00

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

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

shanghai1943

2021-07-01 14:11:29 +08:00

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

linbiaye

2021-07-01 14:22:43 +08:00

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

DeWjjj

2021-07-01 15:14:27 +08:00

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

statement

2021-07-01 15:43:11 +08:00

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

levelworm

2021-07-01 20:36:45 +08:00 via Android

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

saulshao

2021-07-02 14:31:38 +08:00

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