Database 类型表和软件硬编码值

我有这个DB模型：

（

TEXT

实际上是

VARCHAR

）

entity\u group\u type

在运行时不可修改，但开发团队将在不久的将来多次修改它以添加更多条目

现在我需要从

实体

中检索给定

实体_组_类型

的所有条目。软件应该如何处理此类查询？我是否应该在软件中硬编码

实体\组\类型

\u id

/

名称

？如果是这样，那我为什么还要这张桌子呢？还有更好的，硬编码

\u id

或

名称

或者这是构造数据的错误方式

---

提前谢谢

假设您在运行时知道您的

实体组类型的
名称
，然后找到所有
实体组类型为
实体组类型的
名称
，您将使用联接：

SELECT entity_group._id, entity_group.name, entity_group_type.name AS groupTypeName
FROM entity_group
JOIN entity_group_type ON entity_group.id_type = entity_group_type._id
WHERE entity_group_type.name = 'someGroupName';

这将导致
给定实体组类型名称的所有
实体组
信息

是的，这是存储此类信息的一种好方法，或者至少是一种可能的方法。试想一下，
实体\组\类型
最终会获得一个新属性，例如
禁用
。然后，仍然可以很容易地找到所有
实体组
中（未）处于
禁用
类型中的。
我认为您应该按照上面的设计图，将
实体组
存储在数据库中自己的表中。将该信息存储在数据库中可以查询该信息，这为您的设计增加了灵活性

一旦数据库中有了这些信息，您的问题似乎是应该将其分解到自己的表中，还是仅仅作为列存储在
entity_type
表中。我认为您应该将它分解到自己的表中，使用一个从
实体\类型
到
实体\组\类型
的外键约束


将
实体组类型
放在其自己的表中允许保留组类型，即使该类型的所有实体组都已从数据库中删除
您可以利用外键确保
实体\组\类型
名称拼写一致。插入的
实体组
s必须满足外键约束，因此必须引用具有正确拼写名称的现有
实体组类型
，或者插入将为新的
实体组类型
设置正确拼写的
实体组类型


为您的
实体组类型
表使用合成键，以减少
实体组类型
名称外观中令人痛苦的冗余。这使得数据模型更加复杂，并允许将
实体组类型
的名称更新为一个表的简单更新

至于在应用程序逻辑中存储
实体组类型
，我建议存储名称，并在需要时查找
实体组类型
的id。我认为这将使应用程序代码库更具可读性，并且我认为我已经提出了一个令人信服的论点，说明为什么我认为这些相关信息应该在数据库中有一个表示形式。
一次只回答一个问题：

您应该如何引用软件中的实体组？硬编码id或名称？

以使代码最具可读性的方式引用实体组。因此，您可能使用名称，或者使用一个看起来像名称但其值为id的常量。在按组类型查找实体时，使用常量可以避免一次连接，但通常这不太重要

为什么我甚至需要数据库中的表？这是构造我的数据的错误方法吗？

这是一种完全可以接受的数据结构方式。最正确的方法取决于您对数据所做的操作，但对于大多数应用程序，您的结构都是正确的。但是，您当然不需要数据库中的该表——您可以在entity\u group表上有一个“group\u type”字段。以下是优点和缺点：

当前结构的优点：


易于添加描述实体\组\类型的字段。例如，您可能希望使某些组类型仅可由管理员用户查看，或禁用，或其他。如果这在未来是可能的，那么它几乎需要这种数据库结构
能够让数据库软件强制执行引用完整性，这意味着实体组和实体组类型表之间的数据保持一致

在实体组表上添加组类型字段的优点：


可能是代码中更简单的表示形式。例如，如果您使用MVC体系结构，拥有额外的表可能需要在代码中使用另一个模型对象。这通常不是问题，也可能有好处，但有时越简单越好
当您按实体组类型查找实体时，您的SQL语句将稍微简单一些，因为将少涉及一个表/联接

我认为，在大多数情况下，您当前的结构会领先，尽管它确实取决于您如何使用数据。除非你有很好的理由改变数据结构，否则我会坚持你当前的结构。
谢谢，但我知道如何进行查询，这不是问题：）那么我不明白问题。。。实体组类型可能会获得更多的条目，但它是无用的，因为您希望始终获得那些具有特定的
id\u类型的
entity组
s？尽管如此，我还是会选择一个不言自明的名字，这样你以后就可以更改这个名字的_id了。我从来没有问过如何在问题中进行查询：）带你去