【问题标题】:Integer vs char for DB record property数据库记录属性的整数与字符
【发布时间】:2010-12-14 07:28:58
【问题描述】:

假设我有一张包含房地产清单的表格。每个列表都可以是“出售”或“出租”。因此,我可以将“出售”映射到 0,将“出租”映射到 1,并将其作为 INT 存储在数据库中。但是,如果我将它作为“销售”/“租赁”存储在 CHAR 类型的字段中,它会更具描述性。或者我可以在我的程序中将 0 和 1 映射到两个常量 FOR_SALE 和 FOR_RENT。或使用字符“S”和“R”。在一个此类属性的选项总数非常少的条件下,将此类属性存储在数据库中的最佳做法是什么。

【问题讨论】:

  • 有没有可能同时出售和出租的东西?
  • @adam,根据我认识的房地产经纪人的说法,这种情况经常发生。
  • 嗯,关于“同时出售和出租”的观点非常好。我将不得不向房地产经纪人询问这件事。然而,这个问题更笼统。目前我正在使用 MySQL。

标签: mysql database database-design data-modeling


【解决方案1】:

我会将列表中的属性作为 int 存储,并使其成为查找表的外键,您可以在其中添加描述。

【讨论】:

  • 与枚举相比,将它们放在单独的查找表中的优点是您可以在程序的查询中更轻松地使用查找值。
【解决方案2】:

您应该使用 char(1) 或 int(取决于选项的数量)并将值映射到常量字符串,这样您将节省空间并且将来可以轻松配置字符串 :)

【讨论】:

  • 我总是对任何 id 使用 int,包括那些只有很少记录的简单查找表。它更加一致,如果它没有很多记录,也不会浪费太多空间。
【解决方案3】:

PostgreSQL 和 MySQL 支持 enumerated types,这正是您所寻找的。枚举类型的唯一问题是数据库的可移植性。例如,Oracle 没有枚举类型,因此您必须改用 CHAR。因此,例如,如果您使用 PostgreSQL,则没有理由不利用其功能。如果您需要数据库可移植性,使用 CHAR(1) 或 NUMBER(1) 是最有效的。

更新:您可以使用带有外键的查找表,正如其他回复所提到的,但布尔值不会改变,这会引入不必要的复杂性。尤其是当您考虑必须在 ORM 中为它们创建额外的类时。但是,如果您预计该列/变量的值范围会发生变化,那么使用查找表是最好的方法。

【讨论】:

    【解决方案4】:

    对于这么简单的事情,我只会使用char(1);我还会对其施加CHECK 约束(如果可用),以进行一些健全性检查。为只有两个值的东西添加一个额外的表有点毫无意义,即使它是正确的。此外,列中的SR 将在您手动调试或在数据库中闲逛时为您提供帮助,16 将毫无意义。

    当然,如果你有值并且无法想出合理的助记符来表示它们,那么“int and an FK”方法更有意义。

    如果有必要,您可以很容易地从 char(1) 更改为“int and an FK”。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-07-30
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多