【问题标题】:String or Number Codes for Field Values - What's the Best Practice?字段值的字符串或数字代码 - 最佳实践是什么?
【发布时间】:2018-04-02 13:31:16
【问题描述】:

在一个应用程序(在我的例子中,一个具有数据库、服务器和前端层的 Web 应用程序)中,如果您有一个字段的可能值数量有限,那么在数据库上表示它的最佳方式是什么?

例如,假设我们有一个员工状态字段,它可以具有以下值:

  • 活动
  • 已终止
  • 请假

该字段将在层之间传输,并针对不同目的对值进行逻辑处理(例如在网页上用不同颜色突出显示)。

那么,存储这些值的最佳方式是什么,以便 a) 出现错误的可能性较小,但 b) 仍然便于开发人员使用?

该值应该存储为对应于不同状态的枚举 (1, 2, 3),还是纯字符串,或者是一些没有空格的缩短值,例如 (ACT, TER, LOA),还是这样纯粹是偏好问题?我倾向于使用数字,因为您不会遇到拼写错误,但这需要权衡取舍。

对此主题的标签建议表示赞赏。

【问题讨论】:

    标签: database encoding schema field


    【解决方案1】:

    我认为两者都有优点和缺点。 使用数字:

    1. Lesser Size 
    2. Performance
    3. Lesser Error 
    4. Easy To Code
    

    另一方面,在使用 ID 时,一个主要问题是每个需要与 DB 交互的应用程序都需要知道此 ID 及其含义。任何报告工具的主要示例。当然,我们可以通过为每个这样的对象类型创建一个定义表来消除这种影响。即只有两列 ID、DESCR 和一个简单联合的表就足够了。

    使用字符串:

    1. Easy to remember 
    2. Easy for all other Systems directly talking to DB 
    

    【讨论】:

    • 我也是这么想的。如果它只是系统,那么数字可能会更好,或者如果它只是一个你必须翻译的系统,那么数字就可以了。但是如果有 2 个或更多,可能不值得对错别字稍加防范。
    • 但是如上所述,我们总是可以通过创建简单的定义表来否定 imapct,在我看来这仍然比存储字符串更好。另一个问题是,当你想通过这些标签进行查询时,索引字符串的开销会很大。
    猜你喜欢
    • 2011-01-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-15
    • 2017-12-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多