在数据库设计中,状态字段(如status)用0代表成功还是失败,有所谓吗?

探讨数据库设计中状态字段的两种常见编码方式,分析其优劣,特别是在状态增多时的区别。推荐一种更优雅的状态编码策略,便于异常状态的统一检索。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

场景


数据库表中出场率非常高的一类字段就是状态(如status、state等),现在我正在设计一个数据库表,状态字段有“正常”和“注销”两种状态值。通常会出现以下两种使用方式:

0:正常,1:注销

0:注销,1:正常

有些人用第一种,有些人用第二种,有区别吗?

  • 使用第一种方式的蜀黍,我不知道你们怎么想的。
  • 我猜(瞎猜的不一定对)使用第二种方式的小哥哥,想到了boolean类型0表示假、1表示真,所以0代表注销、1代表正常,逻辑非常严谨一致。

剧情发展


就在这千钧一发的时刻,系统迭代过程中增加了几个状态,比如:锁定、过期、拉黑,再比较一下两种方式:

0:正常,1:注销,2:锁定,3:过期,4:拉黑

0:注销,1:正常,2:锁定,3:过期,4:拉黑

这时候,是不是看到一点区别了,有没有发现第一种方式更优雅? 为什么呢?

因为「幸福的家庭都是相似的,不幸的家庭各有各的不幸」?

正常状态只有一种用0表示,1、2、3等分别代表不同的异常情况。好像有点道理啊,更何况还有意外收获,可以用 status > 0 检索所有异常状态。

胡言乱语


再提醒一下上边逻辑严谨一致的那位小哥哥,此处字段名是status而且是数值类型,与boolean类型没有任何瓜葛。如果你的字段名是是is_deleted,我认为你用0代表非、1代表是,那才真是逻辑严谨。

以上就是我的一些胡言乱语,如果你们觉得有点道理,希望帮到你们,如果有说错的地方希望和大家撕逼,哈哈,谢谢!

转载于:https://juejin.im/post/5c6ecea1e51d456598092a96

### 商品管理系统流程图设计 #### 总体流程图描述 商品管理系统的总体流程通常涵盖了初始化、用户操作输入、功能调用以及退出等多个阶段。以下是该系统的一个典型流程概述: - **启动系统**:加载必要的配置文件并初始化数据库连接。 - **显示菜单选项**:提供给用户的交互界面,允许他们选择不同的操作(如添加商品、修改商品、删除商品等)。 - **执行相应命令**:依据用户的选择调用相应的子模块处理逻辑。 - **结束运行**:当用户决定不再继续任何其他操作时安全关闭应用。 这一过程可以用传统的流程图表示出来,其中矩形代表具体的操作步骤;菱形用于决策判断点;箭头则指示控制流的方向[^1]。 对于现代开发环境来说,也可以采用结构化更强的N-S盒状图表来表达相同的业务逻辑,在这种风格下省去了多余的转向线而更加紧凑直观[^2]。 ```plaintext +-------------------+ | Start System | +-------------------+ ↓ +-------------------+ | Show Menu Options | +-------------------+ ↓ +-----------------------------+ | Get User Input & Call Funcs| +-----------------------------+ ↓ +--------------------+ | Check Exit Command?| +--------------------+ / \ No Yes | | ↑ ↓ +---------------+ +-------+ | Loop Back Here| |System End| +---------------+ +-------+ ``` #### 各模块详细流程图说明 ##### 添加商品 (Add Product) 此部分主要涉及新产品的录入工作,需收集必要字段信息后存入数据存储层。其基本步骤如下所示: 1. 开始接收新增请求; 2. 验证表单填写完整性; 3. 如果验证失败返回错误提示重新提交; 4. 成功通过校验之后保存记录到持久介质里去; 5. 结束当前事务并向客户端反馈结果状态消息。 利用标准图形符号描绘出来的样子应该是这样的: ```plaintext +-----------+ |Start Add Prcdure| +-----------+ ↓ +--------------+ |Collect Details| +--------------+ ↓ +------------+ |Validate Data| +------------+ ↘↙ Yes No ↓ ↓ +---------+ +----------+ |Save Record| |Show Errors| +---------+ +----------+ ↓ +-------------+ |Return Success| +-------------+ ``` 同样地,如果偏好简洁明了的表现手法的话,则可以考虑运用NS型布局替代之。 ##### 修改现有条目(Modify Existing Entry) 更新已有项目的过程相对复杂一点因为它除了要经历相似的数据采集环节外还需要额外确认目标对象是否存在有效匹配才行。因此完整的序列应当包括以下几个方面: 1. 初始化编辑模式; 2. 定位待更改实例; 3. 展示原始属性供审阅调整; 4. 接收修订后的参数集合; 5. 实施差异同步至后台仓库; 6. 提交完成后告知前端最终状况报告。 下面是按照常规方法构建而成的设计方案之一: ```plaintext +------------------+ |Initiate Modify Mode| +------------------+ ↓ +----------------------+ |Search Target Item ID| +----------------------+ ↙↘ Item Found Not Found ↓ ↓ +--------+ +-----+ |Load Info| |Abort| +--------+ +-----+ ↓ +-----------------+ |Accept Changes Set| +-----------------+ ↓ +----------------+ |Apply Updates Now| +----------------+ ↓ +----------------+ |Notify Completion| +----------------+ ``` 至于更为精炼的形式自然还是推荐选用前述提到过的另一种呈现方式即所谓的“盒子”样式啦! ##### 删除指定单元(Delete Specific Unit) 最后我们再来看一下移除特定实体所遵循的一般套路吧——它一般由下面这些构成要素组成起来共同完成整个动作链路: 1. 进入销毁预备态; 2. 明确指出打算清除的目标编号; 3. 执行双重身份核验以防误删事故发生; 4. 正式下达指令彻底抹掉关联资料档案; 5. 将处置成果通知相关人员知晓情况进展情形。 对应的可视化表现形态可参照此处给出的例子来进行理解学习哦~ ```plaintext +----------------+ |Enter Delete Prep State| +----------------+ ↓ +-----------------------+ |Specify Target Entity Id| +-----------------------+ ↙↘ Match Exists Match Fails ↓ ↓ +------+ +---------+ |Confirm| |Terminate| +------+ +---------+ ↓ +----------------+ |Execute Deletion Order| +----------------+ ↓ +----------------+ |Report Operation Status| +----------------+ ``` 当然啦,以上所有的例子都可以转换成更接近实际编码习惯的那种分隔清晰易读性强的版本也就是所谓规范化后的NS格式咯~
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值