项目之初的模型设计与status状态字段

0X01

开始做一个app的时候，要先做的是流程设计与数据库模型设计。

但做的模型设计往往是设置字段满足当前的需求，缺乏足够的经验，即使为以后的功能预留出位置，也无法考虑周全。

比如，刚开始做用户表，关于删除用户的功能，一开始预想的是直接删除用户。等到所有功能做完了，这一个版本结束了，在下一个版本迭代中，想要给数据库添加一个删除status字段，删除的时候改status=0，用于标记删除，代替直接删除用户，以记录历史用户数据。

但是看了一遍代码，如果加多一个删除的status字段，需要考虑这个库的各个使用的地方，是不是需要在增删改查的时候加入status的判断，会特别头疼。

0X02

最近的一个需求是我需要做一个数据库数据删除的功能，但是删除完又想有数据回滚、删除数据记录的功能；最好的应该是有一个删除状态，但是这个项目的所有功能逻辑其实我也并不是特别清楚，如果加一个状态，需要先弄清80个使用该表的地方，再进行判断是否需要改动，工作量实在是复杂。

反而是在删除的时候同时插入另一个复制的表，很快就能做完回滚的功能。

前期的模型设计，后期要改动，成本实在是太大了。所以应该尽量在项目开始初期就做好数据库模型的设计，还有功能的预留位置，就算现在版本比较简单，也需要考虑以后迭代更新的时候可能会添加这个功能。尽量设计好一个足够健壮健全的框架，以免迭代的时候还要回头改动框架，那样成本就太大了。这也是与经验有关，但不要以经验不足为借口就不做了。经验不足，调研辅助，思考为主。

0X03

另一个点是，在加状态来判断几种状态之前，先考虑一下，能不能从数据库中的其他字段中判断出状态的不同。

比如说，原本我这个表中只存广东人，所以所有模型设计都是依靠广东人的。之后需要加一个需求，东北人的数据也要接入这个表中。

其实加一个来源字段是最科学的方法。但是如果可以从其他字段，比如户籍、户口、住址、口音这些地方来判断来源，那么更容易做的是用其他字段来判断，加一个来源字段实在是成本太高了，而且相比现有字段判断，显得更加鸡肋。

—————————做完了状态判断的流程后，发现有一个字段可以很简单的判断，于是把之前的改动都删除掉，再两三句代码改完。当改完的时候有点想哭，记下来，长点脑子。