【问题标题】:Best practice for storing enums and user defined values存储枚举和用户定义值的最佳实践
【发布时间】:2014-06-18 23:06:24
【问题描述】:

我需要在数据库中存储支付类型枚举值以进行记录。

问题是我想添加最终用户定义自己的值类型的能力。

我知道我可以在枚举中为自己的值使用负范围,因为用户定义类型的 id 大于 0,但这是正确的方法吗?

或者我应该有第二列,如 CustomPaymentType 并引用 PaymentType 表以实现数据一致性?

【问题讨论】:

标签: c# database


【解决方案1】:

不要使用枚举。

枚举只对本质上是固定不变的事物有用,例如一周中的几天。

改为使用数据库中的参考表,例如 CustomPaymentType (Id,PaymentTypeName) 那么您可以使用如下所示的类:

public class CustomPaymentType
{
    public string paymentTypeName { get; private set; }
    public int Id { get; private set; }

    // if you need "Constant payment types usable in code, just add something like:
    public static CustomPaymentType CashPayment
    {
        get { return new CustomPaymentType() { Id = 7, paymentTypeName= "CashPayment" } }
    }

    public static CustomPaymentType CreditPayment
    {
        get { return new CustomPaymentType() { Id = 7,paymentTypeName= "CreditPayment" } }
    }
}

这种方法非常好,因为您既可以轻松编码在编码时可能需要的众所周知的特定实例,而且还具有很强的可扩展性。

【讨论】:

  • 不确定我明白了。您是否建议在数据库中拥有所有类型?如果是,那么我只需要在创建数据库时生成预定义类型?
  • @NullReference 是的...您甚至可以在不打开代码的情况下添加另一种付款类型,只需在某处扔一个 dll,并添加一些配置以让程序知道该 DLL
  • 好的。您认为对预定义方法使用负 id 是否会更好,这样就不会与用户定义的方法发生冲突?
  • @NullReference 我认为你选择使用哪个 id 并不重要,只要你在用户尝试定义一个已经存在的 id 时给他一个错误。
  • 基本上,负 id 只会帮助识别内置支付,因此例如它的名称可以独立于它在数据库中的实际名称进行本地化。是的,当然,因为 id 生成将在代码中完成,而不是在数据库端,确保 id 的唯一性是必需的。谢谢!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-10-19
  • 1970-01-01
  • 1970-01-01
  • 2013-11-09
  • 2021-08-05
  • 2011-07-16
相关资源
最近更新 更多