我有一个表，代表通过前端发送的请求
coupon_fetching_request
---------------------------------------------------------------
request_id | request_time | requested_by | request_status
以上，我试图创建一个表来解决该问题。
这里的request_status是integer。它可能具有一些值，如下所示。
1 : request successful
2 : request failed due to incorrect input data
3 : request failed in otp verification
4 : request failed due to internal server error
该表非常简单，状态用于让前端知道发送的请求发生了什么。我与我的团队进行了讨论，其他开发人员提议我们应该有一个状态表示表。在数据库方面，我们将不需要此状态。但是团队说，将来我们可能需要显示数据库的简单输出以显示所有请求的状态。根据{{3}}原则，我认为这不是一个好主意。
当前，我已经编码为将返回的request_status值转换为前端的描述性值。我试图说服团队，我可以在业务层创建一个枚举来表示状态的含义，或者可以在前端和Java中添加文档，但是无法说服他们。
建议的表格如下
coupon_fetching_request_status
---------------------------------------------------
status_id | status_code | status_description
我的问题是，在类似情况下是否有必要为这种简单状态创建表。
我试图创建一个简单的示例来解决该问题。该表将实时显示折扣优惠券代码请求，状态表示代码是否成功获取
答案 0 :(得分：1)
这实际上取决于您的用例。
开始于：在主表中，您已经将request_status存储为整数，这是一件好事（如果您要像'request successful'这样存储整个描述，则不会优化）。
主要问题是：您最终是否需要以人类可读的格式显示该数据？
如果否，则创建表示表可能没用。
如果是，那么拥有一个表示表将是一件好事，而不是在表示层中添加一些代码来进行转码；让数据存在数据库中，而前端仅负责表示。
由于可以在需要时轻松创建此表，因此务实的方法是一直坚持到您真正需要表示表为止。
答案 1 :(得分：1)
您应该在数据库中创建引用表。当前，您在应用程序端具有业务逻辑，解释存储在数据库中的数据。这似乎很危险。
“危险”是什么意思？这意味着数据库上的临时查询可能需要重新实现逻辑。这很容易出错。
这意味着如果添加报告前端，则报告必须重新实现逻辑。这很容易出错，而且是维护噩梦。
这意味着，如果您有其他开发人员或实施了其他模块，则可能需要重新实现逻辑。红旗。
最简单的解决方案是拥有一个参考表来定义代码的正式含义。应用程序应使用此表（通过join）返回字符串。该应用程序不应定义存储在数据库中的代码的含义。 YAGNI不适用，因为应用程序非常需要此信息，因此它自己实现了逻辑。