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
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
这是一个创建于 1642 天前的主题，其中的信息可能已经有所发展或是发生改变。
虽然我已经工作 3.4 年,但是我在设计数据库建表的时候，总会在写代码写到一半的时候，才发现自已当时设计表有问题,还需要重新调整,数据表结构变，代码又要变了.这样效率太低了。
比如建立一个商城分销,最基本的用户表,分拥表,资金变动表,统计表,商品表,订单表，退款表，商户表...等。 一开始的正常逻辑，用户下单购买 50 元的商品，付款后，过了 7 天后自动收货,确认已经完成。然后开始奖励下级的代理与店铺分拥。
但是过了半年后,经过资本家的密谋,说要把逻辑修改一下,用户下单后，代理不能看到 50 元的订单,把订单随机修改为了<=50 元，目的不让代理分拥太多。必要时刻干脆把订单隐藏了，让代理没有这个订单。说白了就是要在商城里面添加暗操作。还有等等的骚操作。
所以现在如果修改代码,就涉及很多表要修改了，工程量也多。我该如何避免设计之后的表无法满足后续的迭代升级，有专门设计建模型的书籍推荐看看吗
 | 1 leon0318 2021-07-01 14:03:24 +08:00 via iPhone 我理解需求变更导致表结构变更是正常的，但还是同求工作 10 年以上大佬指点指点 |
 | 2 ChoateYao 2021-07-01 14:09:53 +08:00 这就是软件开发的痛点，你永远不会知道下个需求要做什么。 就好比本来用户名是唯一的，一段时间过后用户名允许重复，这种需求你永远没有办法预估。 |
 | 3 shanghai1943 2021-07-01 14:11:29 +08:00 依个人浅薄意见，关于扩展性这些东西是能想到的就尽量先想到，想不到的就不强求，先满足当下功能最重要，毕竟往后的需求变动了，需要改成啥样并不知道，假如现在提前铺好了扩展性，但是往后需要改的不是这个样子，有可能就是白费劲了，所以满足当下是第一优先。 |
 | 4 linbiaye 2021-07-01 14:22:43 +08:00 这个没有办法，新需求和以前的逻辑，设计冲突太正常了。 |
 | 5 DeWjjj PRO 我的做法是旧表迁移新表 字段不重复利用。 相当于订单不重复，或者订单需要改形式。旧订单号原地不动，全部迁移到新订单上。 |
 | 6 statement 2021-07-01 15:43:11 +08:00 扩展是未知的。但好的设计。肯定是易扩展的 开始不过度设计 但扩展性要高 |
 | 7 levelworm 2021-07-01 20:36:45 +08:00 via Android 需求变更的确没办法，除非你能猜到老板将来的想法。而且这个未必需要数据库变更。 |
 | 8 saulshao 2021-07-02 14:31:38 +08:00 没有任何办法能解决你提到的问题，什么叫变更？变更就是你之前无法预料，当它要发生你才知道。 |
Select Language