查询表过多

在数据库中有太多的查找表有什么不利影响？查询表过多

我必须根据应用程序列举太多的枚举。

专家会提出什么建议？

来源

2010-07-22 iims

Ooohh ...我也需要知道这个答案！ :) – gillyb 2010-07-22 17:23:58

定义“太多的枚举，基于应用程序” – 2010-07-22 17:24:49

请定义“太多的查找表”。对于我来说，当查找表没有被使用时，“太多的查找表”就会出现。在这种情况下，这种不利影响会变得混乱，从而减慢对系统的推理。 – 2010-07-22 17:26:18

最初你必须问自己“有多少？”。如果两个表格之间存在逻辑关系，则必须有FK。

如果您不需要数据库中的任何地方的相关表，你可以考虑将其删除，并使用CHECK约束有“IN”的条款来执行数据的有效性。尽管如此，这将导致枚举中每个新值的表的更改。

我的个人建议是保留FK和表格。这是一个明确的解决方案，如果所有这些数字都有可用的描述文本，则数据库更好地维护。

来源

2010-07-22 17:28:16

查找数据的整点是有一个特定字段的有效标识符的有限列表。如果这些特定字段用于过程或用于确定正确流程路径的语句或限制选择列表中，则不存在查询太多的情况。

如果不是标识符的特定过程或where子句那么它们不应该是一个查找值的有限列表。

两种浮现在脑海中都可能被视为查找值，但并不一定需要的字段。

市和省/州：

有这些有限的名单，但因为有很多的sooo你可能不想让这些查找。

来源

2010-07-22 17:32:11 greektreat

由于弗洛里安，我想了很多更要有吨外键，然后有CHECK IN（..） - 理由很简单：您可以在表中插入其他记录。

Maintaning CHECK IN（）是一个更大的问题。想象一下这个场景：

CREATE TABLE street 
(
    id serial not null, 
    st_type varchar(20) not null, 
    st_name varchar(100) not null, 
    constraint street_pk primary key (id) 
    constraint street_type_check check st_type in ('STREET','AVENUE','SQUARE') 
);

你有1000行检查这些类型，正确吗？如果您需要添加另一个，则需要删除约束并重新创建它。

如果你把一个项目关闭该列表中，像正方形，会发生什么事是有类型已经COMMITED（在插入的时刻选中）行？他们仍然保持无效的类型。

表和外键更易于维护和跟踪。

来源

2010-07-22 17:34:42

让我告诉它有多少查找表太少。我工作过的原始设计人员决定将所有查找放入一张表中，并定义查找使用typeid的内容。这导致几乎所有查询都会触发该表以获取导致性能堵塞的查找描述性值。

此外，没有单独查询，即采取了typeid的领域没有被适用于该领域，因为一个外键只能是对整个表不是一个块中的值的约束。因此，存储该clientid的字段可能会意外地包含用户组的值。这导致了数据完整性问题，并使报告变得更加困难，因为我们必须解释在上下文中没有意义的值。使用太少表格没有奖励，实际上它通常是数据库设计中的反模式。

如果这是您需要的，请创建1000个查找表。

来源

2010-07-22 17:56:37 HLGEM

回答

相关问题