使用我自己的枚举类型对数据库中的模型类进行建模

发布于 2024-08-06 19:58:48 字数 547 浏览 10 评论 0原文

我有一个应用程序需要查询生命表(用于保险计算)。 我正在考虑使用 XML 来存储数据,但认为它有点大,但对于使用成熟的数据库来说可能有点小。所以我选择使用SQLite。

在我的应用程序中,我有枚举定义了一些不同的东西。例如,性别.男、性别.女。以及 JOBTYPE.BlueCollar、JOBTYPE.WhiteCollar。等等等等。

我有一些如下所示的方法:(示例)

FindLifeExpectancy(int age, GENDER gender);
FindDeathRate(int age, JOBTYPE jobType);

所以我的问题是:如何在数据库中对枚举进行建模?我认为在数据库中使用 0 或 1 来存储 JOBTYPE 不是最佳实践,因为这对于任何查看它的人来说都是毫无意义的。但如果你使用nvarchar来存储“BlueCollar”,就会有很多重复数据。

我认为 GENDER 或 JOBTYPE 不应该有一个完整的类,或者作为实体模型的一部分,因为它们提供的信息很少。

这通常是如何完成的?

谢谢。

I have an application that I need to query lifetables (for insurance calculation).
I was thinking about using XML to store the data, but thought it was a little big, but maybe a little small for using a full-fledged database. So I chose to use SQLite.

In my application, I have enums defining a few different things. For example, GENDER.Male, GENDER.Female. and JOBTYPE.BlueCollar, JOBTYPE.WhiteCollar. etc etc.

I have some methods that look like this: (example)

FindLifeExpectancy(int age, GENDER gender);
FindDeathRate(int age, JOBTYPE jobType);

So my question is: How do you model enums in a database? I don't think it is best practice to use 0 or 1 in the database to store JOBTYPE because that would be meaningless to anyone looking at it. But if you used nvarchar, to store "BlueCollar", there would be a lot of duplicate data.

I don't think GENDER or JOBTYPE should have an entire class, or be apart of the entity model because of the little information they provide.

How is this normally done?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

開玄 2024-08-13 19:58:48

我更喜欢将程序中的枚举静态映射到数据库中的查找表。我很少实际使用查找表来进行连接。作为一个例子,我可能有下表:

Gender
GenderID  Name
1         Male
2         Female

Accounts
AccountID  GenderID  FirstName  LastName
1          1         Andrew     Siemer
2          2         Jessica    Siemer

然后在代码中我将使用适当的映射定义枚举

public enum Gender
{
    Male = 1,
    Female = 2
}

然后我可以在代码中使用我的枚举,当我需要在 LINQ to SQL 查询中使用枚举时我只需获取它的像这样的物理值

int genderValue = (int)Enum.Parse(typeof(Gender), Gender.Male));

尽管您刚刚将代码与数据库中的值耦合,但这种方法可能会让一些人感到有点奇怪!但这种方法使得处理代码和支持该代码的数据变得更加容易。一般来说,如果有人交换了查找表的 ID,那么您将会以某种方式受到攻击,因为它无论如何都会映射到您的数据库中!不过,我更喜欢这种设计的可读性和普遍性。

I prefer to statically map my enums in my program to a lookup table in my database. I rarely actually use the lookup table to do a join. As an example I might have the following tables:

Gender
GenderID  Name
1         Male
2         Female

Accounts
AccountID  GenderID  FirstName  LastName
1          1         Andrew     Siemer
2          2         Jessica    Siemer

And in code I would then have my enum defined with the appropriate mapping

public enum Gender
{
    Male = 1,
    Female = 2
}

Then I can use my enum in code and when I need to use the enum in a LINQ to SQL query I just get its physical value like this

int genderValue = (int)Enum.Parse(typeof(Gender), Gender.Male));

This method may make some folks out there a bit queezy though given that you have just coupled your code to values in your database! But this method makes working with your code and the data that backs that code much easier. Generally, if someone swaps out the ID of a lookup table, you are gonna be hosed in some way or another given that it is mapped across your database any how! I prefer the readability and ubiquitous nature of this design though.

我的黑色迷你裙 2024-08-13 19:58:48

虽然您不太可能添加新的性别,但我对工作类型枚举不太确定。我会为两者使用一个单独的表,并且在每个需要引用它们的地方都有该表的外键。该模式将是可扩展的,数据库将自动检查是否仅将可能的值保存在引用表中。

While it's unlikely that you will be adding a new gender, I wouldn't be so sure about the jobtype enum. I'd have used a separate table for both, and have foreign keys to this table every where I need to reference them. The schema will be extensible, the database will automatically check that only possible values are saved in the referencing tables.

情感失落者 2024-08-13 19:58:48

SQL 中“枚举”的等价物是查找表。这些表格包含两列(有时更多列):

  • 代码,通常是短数字或字符(例如:“R”、“S”、“M”...)、
  • 文本定义(例如:“退休”、“学生”) '、'军事'...)
  • 额外的列可用于存储定义或文本的替代版本,例如列式报告的简短缩写)

短代码是存储在数据库中的值的类型,避免了复制提及。对于相对确定的类别(例如男性/女性),您可以只使用代码,而不将其“记录”在查找表中。

如果您有很多不同的代码,最好将它们的查找保留在单个 SQL 表中,而不是使用大量的表。 的代码组的性质(“婚姻状况”、“就业”、“教育”...)

您可以简单地添加一个“类别”列,该列本身就是一个代码,指定此类别中定义 查找表中的内容可用于填充 UI 中的下拉列表等,最终用户可以在其中看到明文,但应用程序可以使用代码来查询数据库。它还用于相反方向,为数据库中找到的代码生成明文,用于显示结果列表等。

SQL 级别的JOIN 构造是关联查找表和主表的便捷方法。例如:

SELECT Name, Dob, M.MaritalStatus
FROM tblCustomers C
LEFT OUTER JOIN tblMaritalLkup M ON C.MStatus = M.Code
WHERE ...

The SQL equivalent of 'enums' are lookup tables. These are tables with two (sometimes more) columns:

  • a code, typically short, numeric or character (ex: 'R', 'S', 'M'...)
  • a text definition (ex: 'Retired', 'Student', 'Military'...)
  • extra columns can be used to store definitions, or alternate versions of the text for example a short abbreviation for columnar reports)

The short code is the type of value stored in the database, avoiding the replication you mentioned. For relatively established categories (say Male/Female), you may just use a code, without 'documenting' it in a lookup table.

If you have very many different codes, it may be preferable to keep their lookup in a single SQL table, rather than having a proliferation of dozen of tables. You can simply add a column that is the "category", which itself is a code, designating the nature of the group of codes defined in this category ("marital status", "employment", "education"...)

The info from the lookup tables can be used to populate drop downs and such, in the UI, wherey the end-user sees the clear text but the application can use the code to query the database. It is also used in the reverse direction, to produce the clear text for codes found in the database, for displaying results list and such.

A JOIN construct at the level of SQL is a convenient way to relate the lookup table and the main table. For example:

SELECT Name, Dob, M.MaritalStatus
FROM tblCustomers C
LEFT OUTER JOIN tblMaritalLkup M ON C.MStatus = M.Code
WHERE ...
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文