数据库表字段设计小白问题

Question

心塞塞，昨儿提了个解决方案被否了，理由是不符合产品设计规范；
需求如下：表里想设计一个状态字段status，这个状态包括的值有：1设计，2变更，3执行等，然后由于并发的问题，需要给状态加锁的标志位，意思就是并发状态下，有一人在执行时，先给状态加锁，其他人就不能对该条数据进行其他相关操作了。
我的方案是：状态列设计为两位的存储方式，第一位用来表示状态的使用值，第二位用来表示是否锁住，类似于10表示设计状态下没有锁，11表示设计状态下加锁。我觉得没有必要再加一个字段去标识是否加锁，数据库本身的字段就很多了，而且我认为这锁状态和原有状态是一种组合的方式。
这种一个字段多位的处理方式在我之前几家公司都有用到过。可是这里却说这样的设计不符合规范。
我查了数据库设计规范，第一范式要求属性具有原子性，不可拆分，难道说我这样的设计是不符合第一范式的要求？
望大牛指点~

PS：申明一点，就是数据库锁，一开始我提的方案也是用数据库锁，但是数据库锁会有几个问题：
第一就是如果用数据库的锁，在两人同时修改提交的时候，肯定会有一个人的修改被退回导致操作被浪费，这是业务上不允许的；
第二就是业务上并不是只操作一张表，执行阶段操作的并不是主数据本身，而是他的一些附表；我们是想通过在主表上加锁字段来判断这条数据的其他附表操作是否可以被做；

还有我最想问的是，多位存储状态的列设计是否不符合数据库设计

Answer 1

你是把业务所需要的操作和数据库操作混一起考虑了。业务状态的值和变更依赖于业务逻辑处理，数据库的锁依赖于数据库。
可以考虑把业务状态加个锁定的值。如设置锁定为4，你的表里肯定有一些数据字段，设为data吧，可以类似：
update table1 set data='data...', status='4' where id='xxx' and status='1'
操作修改提交，一步就把数据和状态修改了。

这种情况再提交一定失败，因为status不再是1。然后你再考虑其他状态什么情况发生和处理，比如审核操作可以把status再改为1或者2，或者3。