2013-02-01 155 views
1

我有这个DB模式:类型表和软件硬编码值

DB model

TEXT实际上是VARCHAR

entity_group_type是不能在运行时修改的,但它会在不久的将来被修改开发团队多次添加更多条目。

现在我需要检索entity中给定entity_group_type的所有条目。该软件应该如何处理这种查询?我应该在软件中硬编码entity_group_type_id/name?如果是这样,为什么我甚至需要这张桌子呢?还有什么更好的,硬编码_idname

或者这是错误的方式来构建我的数据?

在此先感谢!

回答

2

以你的问题,一次一个:

你应该如何参考实体组中的软件?硬编码的身份证,或名称?

以使您的代码具有最高可读性的方式引用实体组。所以,也许你使用了这个名字,或者是一个看起来像名字但是其值是id的常量。使用常量可以避免在按组类型查找实体时进行一次连接,但通常这并不是什么问题。

为什么我甚至需要DB中的表格呢?这是错误的方式来构建我的数据?

这是一种完全可以接受的方式来构建您的数据。最正确的方法取决于你对数据做什么,但对于大多数应用程序,你的结构是正确的。但是,您肯定不需要需要该数据库中的表 - 您可以改为在entity_group表上具有“group_type”字段。这里有利弊:当前结构的

优点:

  • 轻松添加描述entity_group_type领域。例如,您可能希望创建一些只能由管理员用户查看或禁用的组类型,或者其他类型的组。如果这是未来的可能性,它几乎需要这种数据库结构。
  • 能够让您的数据库软件实施参照完整性,这意味着entity_group和entity_group_type表之间的数据保持一致。

优势在entity_group表中新增group_type领域:

  • 可能在你的代码更简单的表示。对于exameple,如果您使用MVC体系结构,那么拥有额外的表可能需要代码中的另一个模型对象。这通常不是问题,可能有优势,但有时候更简单更好。
  • 当您按实体组类型查找实体时,您的SQL语句会稍微简单一些,因为涉及的表/联接会少一个。

我认为在大多数情况下,您的当前结构是超前的,尽管它取决于您如何使用数据。除非你有充分的理由来构造数据,否则我会坚持你当前的结构。

+0

谢谢,非常好的解释利弊:) – m0skit0

0

考虑,你知道你的entity_group_type在运行时,那么正确的找到所有entity_group s的那entity_group_type.name方式name,你可以使用一个连接:

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_group信息为given entity_group_type name

是的,这是一种很好的或至少可能的方式来存储这种信息。试想一下,entity_group_type最终会得到一个新的属性,例如disabled。然后,仍然可以容易地找到所有,它们是(不)在disabled类型中。

+0

谢谢,但我知道如何做查询,这不是问题:) – m0skit0

+0

然后,我没有得到问题... entity_group_type可能会得到更多的条目,但它是无用的,因为你想要总是得到那些'entity_group'无论如何,有特定的'id_type'?不过,我会用一个不言自明的名字,以便稍后可以更改该名称的_id。 –

+0

我从来没有问过如何在quesion中进行查询:)考虑你的答案,问题是在哪里/如何存储'someGroupName'字符串。我应该在软件中硬编码吗?如果是这样,为什么我甚至需要DB中的表格呢?硬编码最好是:'name'还是'_id'?如果不是,我该如何处理这种情况? – m0skit0

1

我认为你应该在数据库中确定地存储entity_group_type在它自己的表中,根据你上面的设计图。将该信息存储在数据库中可以根据该信息进行查询,从而为您的设计增加了灵活性。

一旦你在DB中获得了这些信息,你的问题似乎是应该分解到它自己的表中,还是只作为列存储在entity_type表中。我认为你应该把它分解到它自己的表中,外键约束从entity_typeentity_group_type

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

使用您的entity_group_type表的合成密钥,以减少名称外观外观中的痛苦冗余。这使得数据模型更为DRY,并且允许将entity_group_type的名称更新为对一个表的简单更新。

至于在您的应用程序逻辑中存储entity_group_type,我会建议存储名称,并在需要时查找entity_group_type的ID。我认为这会使应用程序代码库变得更可读,而且我认为我为什么认为这些相关信息应该在数据库中有一个表示形式是一个引人注目的论点。