2017-02-21 104 views
0

我有一个报价状态,它是草稿,发送,赢得或丢失。通常我会用Id,Name创建一个查找表,然后通过quote_status_id链接,但在这种情况下,由于状态是系统管理的,例如用户不能创建状态,是否更好地使用字符串呢?sql查询ID与固定字符串

在我的具体情况下的FYI我正在开发一个休息API和多个前端,例如SPA和移动应用程序,所以我需要保持后端和前端之间的状态同步,但根据状态有一些用户工作流程。这可能不会影响我最初的问题,但我想知道如果字符串可能会简化我的发展甚至轻微。

回答

2

你绝对想要支持查找表而不是固定字符串。使用查找表的可维护性有很多原因,但对我来说,它归结为数据安全性的一个核心价值。

在任何全栈应用程序中,您最信任数据库数据,因为它是最持久的。按照这个思想,你想要建立你的数据库,使其尽可能难以数据最终处于无效状态。外键是在支持这个令人难以置信的强大,因为你可以做很多事情,包括:

  • 确保报价总是有一个有效的状态(如果这是你的愿望)
  • 防止从任何用户/开发者的拼写错误坚持数据库(例如创建一个“droft”报价状态)
  • 在一个地方轻松地更新显示名称(如果需要它,“Won”可以更改为“Acquired”并且您不必检查对于您的代码库中的每个参考)

数据库中的自由文本字段应该主要用于自由文本。如果这些值是预定义的并且永远不会改变,那么查找表就是要走的路。

0

字符串很好。一个id和参考表具有很好的优点,您可以验证进入该字段的拼写和值。另外,如果状态存储在多个表中,则参考表确保在所有引用表中使用相同的值。

然而,在一个表中的值,一个check约束作品几乎还有:

alter table t add constraint chk_t_status check (status in ('DRAFT', 'SENT', 'WON', 'LOST')); 
+0

一个缺点,使用检查约束的是,你失去了一些未来的可维护性。假设您想为每种状态添加说明,现在您必须在桌面上创建一个包含重复数据的附加列。我并不是说答案是错的,但作为一名DBA,我更喜欢用“期待一切在6个月内改变”的态度来对待设计。你会以这种方式更少支持哈克修补程序。 – Dmihawk