数据库表字段设计小白问题
心塞塞，昨儿提了个解决方案被否了，理由是不符合产品设计规范；
需求如下：表里想设计一个状态字段status，这个状态包括的值有：1设计，2变更，3执行等，然后由于并发的问题，需要给状态加锁的标志位，意思就是并发状态下，有一人在执行时，先给状态加锁，其他人就不能对该条数据进行其他相关操作了。
我的方案是：状态列设计为两位的存储方式，第一位用来表示状态的使用值，第二位用来表示是否锁住，类似于10表示设计状态下没有锁，11表示设计状态下加锁。我觉得没有必要再加一个字段去标识是否加锁，数据库本身的字段就很多了，而且我认为这锁状态和原有状态是一种组合的方式。
这种一个字段多位的处理方式在我之前几家公司都有用到过。可是这里却说这样的设计不符合规范。
我查了数据库设计规范，第一范式要求属性具有原子性，不可拆分，难道说我这样的设计是不符合第一范式的要求？
望大牛指点~
PS：申明一点，就是数据库锁，一开始我提的方案也是用数据库锁，但是数据库锁会有几个问题：
第一就是如果用数据库的锁，在两人同时修改提交的时候，肯定会有一个人的修改被退回导致操作被浪费，这是业务上不允许的；
第二就是业务上并不是只操作一张表，执行阶段操作的并不是主数据本身，而是他的一些附表；我们是想通过在主表上加锁字段来判断这条数据的其他附表操作是否可以被做；
还有我最想问的是，多位存储状态的列设计是否不符合数据库设计
你是把业务所需要的操作和数据库操作混一起考虑了。业务状态的值和变更依赖于业务逻辑处理，数据库的锁依赖于数据库。
可以考虑把业务状态加个锁定的值。如设置锁定为4，你的表里肯定有一些数据字段，设为data吧，可以类似：
update table1 set data='data...', status='4' where id='xxx' and status='1'
操作修改提交，一步就把数据和状态修改了。
这种情况再提交一定失败，因为status不再是1。然后你再考虑其他状态什么情况发生和处理，比如审核操作可以把status再改为1或者2，或者3。
如果是并发问题，直接用数据库的锁就行了，不必要在添加一列作为锁的标志。数据库本身就是有锁的，在有人操作数据的时候加一个锁就行了
对某一行或者某个表都可以加锁，看题主需求加一个TABLOCKX 即可
SELECT * FROM 表 WITH (TABLOCKX)
我建议，字段要有其关键意义，锁定应该优先于状态字段，如果使用同一字段在交叉操作数据时锁定会有问题。
如你之前设计 1 ；2；3 ；10 ；11； 数据处理的判断逻辑会出问题，在流程以及其他业务处理时字段值唯一比较有利于操作。
数据库本身就是有锁的啊
通过事物的隔离级别控制
应该是不符合公司内部的产品设计规范---单个字段其含义具有唯一性，跟第一范式是两码事了。
你这样一来，单个字段其实包括两个含义，要求程序员读取后再解析，不符合贵公司内部产品设计规范。
其实你要么直接加一个字段，估计就符合产品设计规范了。
如你所说，已经有很多列了，则可以将表拆分；依业务逻辑将此表拆成多个表，由外键关联；至少可以节约存储空间了。
至于锁定，你即使增加了一个字段，也需要加锁了。要不并发时，一个想改成1，一个想改成2，这种事情也是会发生的了；这称之为数据库锁。
至于将字段置为已经锁定，则称之为业务逻辑锁了，是由程序员控制的了。
只要有可能并发，并且需要适应这种情况，则两把锁都是要的了。
还是加一个字段吧，采用乐观锁的方式！