Question

您好我在我的项目中遇到了这种情况，人们在应用程序中对主键列的值进行硬编码。这是一个好习惯。在处理环境时，该记录的价值可能会发生变化，但如何将身份插入用于其他环境。

Answer 1

虽然这显然是一种非常糟糕的做法，但如果没有关于推理的正确信息，我会毫不犹豫地拒绝这样的事情。我经常给同事们带来怀疑的好处，并假设他们已经考虑过这个问题并得出一个合理的结论，我只需要学会理解他们的推理。

在某些非常罕见的情况下，硬编码标识可以是一个好的解决方案，例如，如果您的安装包还创建数据库和架构并播种某些域查找值，以便它们在每个系统上都相同。在这些情况下，标识列定义的种子比平常略高（例如IDENTITY(100,1)），系统值始终位于种子下方（在本例中为100）。

例如，您可能拥有PhoneType的域表，而值＃1-3保留用于＆＃34; Primary，＆＃34; ＆＃34;帐单，＆＃34;和＆＃34;联系。＆＃34;同时允许最终用户使用100及以上的值来定义自己的手机类型。

在运行时间插入硬编码的身份值绝对是一种不好的做法，例如：响应用户输入。在这种情况下，最好找到一个自然键，使用GUID，或开发自己的身份跟踪系统。

Answer 2

通常我已经看到了代码库中存在常量（如某些基本系统类型的枚举，这些是应用程序的基础），这些常量也存在于数据库中（作为查找表）。有一些更好的方法可以解决这个问题，但最终，即使它不是主键，在这些情况下总会有硬编码。例如，主键可能是自然键。

通常，您只会看到这对于非常基本的实体是可接受的。也许是程序中的一种组织或实体，如：TYPE_USER，TYPE_GROUP。您不会看到这些通常是用户可修改的，或者期望可扩展的查找，或者在某种程度上不是基础的查找，例如VEHICLE_TYPE_CAR，VEHICLE_TYPE_SUV，VEHICLE_TYPE_RV，VEHICLE_TYPE_MOTORCYCLE等。

在任何情况下，这都是一种代码嗅觉，除非它在架构中是一个基本的不可变枚举，否则它不是一个好主意。

Answer 3

我同意迄今为止的所有回复，并且我还面临某些情况，我需要检查某个基于主键的值的条件。正如Siyual已经指出的那样，针对更具说明性的领域检查这一条件更有意义。

处理此问题的一种方法是在描述行的实体中添加另一列，并将其用作映射到枚举的条件检查。

e.g。表：

+-----+----------+-------------+
| PK  |  Status  | Enum_mapped |
+-----+----------+-------------+
| 101 | Fitted   |           1 |
| 201 | Unfitted |           2 |
| 301 | Used     |           3 |
+-----+----------+-------------+

代码：

private enum Statuses
{
    Fitted,
    Unfitted,
    Used
}

private int GetStatus(int enumstatus)
{
    return enumstatus = ctx.myStatus.Where(a => a.Enum_mapped == enumstatus).Select(a => a.PK).FirstOrDefault();
}

调用适当的状态：

GetStatus((int)Statuses.Fitted);

结果= 101

应用程序中的硬编码主键值

3 个答案: