性能 - 诠释与Char（3）

我有一个表，我正在辩论2种不同的方式来存储信息。它有像这样性能 - 诠释与Char（3）

INT ID

INT FK_id

VARCHAR（50）INFO1

VARCHAR（50）INFO2

VARCHAR（50）INFO3
的结构
int forTable or char（ 3）forTable

的FK_id可以是一个外键6个表中的一个，所以我需要另一个领域，以确定它是哪个表。

我看到两个解决方案：

一个整数，它是一个FK到有其实际值设置表。
带有表格缩写版本的char（3）字段。

我想知道如果任何人都知道，如果一个会更有益的速度明智比其他或有将使用CHAR（3）

注意什么大问题：我将创建一个索引查看该字段的6个不同值。这个表格将包含约30k行，需要连接更大的表格

来源

2010-02-18 corymathews

表定义的第一行是什么意思？ ** int id int FK_id varchar（50）** – 2010-02-18 19:30:20

因此，FK值可以是6个其他表中的1个PK？ – 2010-02-18 19:31:39

@KM这意味着编辑找到了我。现在修复它。 @iKnowKungFoo正确。这是因为它在每个表中都是相同的信息，但我需要能够访问它的任何一个，而不必将6个表中的每个表联合起来。 – corymathews 2010-02-18 19:33:13

在这种情况下，它可能不除整理开销（A VS a VS ä VA à）关系

我会使用CHAR（3），说像瑞士法郎，英镑等货币代码但如果我的自然关键是“瑞士法郎”，“英镑”等，我会拿数字。

3字节+整理vs 4字节数字？你需要一个十亿行或运行一个中等规模的国家才能实现...

来源

2010-02-18 19:33:04 gbn

你有没有考虑过使用TinyInt。只需要一个字节来存储它的值。 TinyInt的值范围在0到255之间。

来源

2010-02-18 19:30:58

没有专门查看数据我怎么知道哪个数字与哪个表一起使用？特别是从现在起一个月左右。还有，这只是一个正常的int，这是一个FK的设置表，将包含相应的表的名称有很多好处？ – corymathews 2010-02-18 19:42:07

只有约30K行，可能根本没有太大的差别。事实上，我怀疑你会注意到int，small int，tiny int或char（3）之间的任何区别。此外，如果您在此表中只有6个不同的值，那么它可能不足以成为索引中第一列的合适候选者。 – 2010-02-18 19:46:39

我认为这里需要一个小整数（tinyint）。一个“缩写版”看起来太像一个幻数。

我也认为性能明智的整数应击败char（3）。

来源

2010-02-18 19:31:24

简写版本对于人员或类似用户来说可能是“ppl”。 – corymathews 2010-02-18 19:40:45

首先，一个50个字符的ID不是全球唯一的，听起来有点可怕。这些ID有一些意义吗？如果没有，你可以很容易地获得一个GUID在更少的空间。就我个人而言，我是一个尽可能让事情变得人类可读的风扇。我会，并且已经把图的全名放在图表中，直到我需要做其他事情。我的偏好是尽可能为每个可能的相关表格建立链接表。

除非你正在谈论真正的大规模，否则你最好减少ID的大小，并为表的名称增加几个字符。对于真正的大规模，我会减少ID的大小并使用一个整数。

雅各

来源

2010-02-18 19:33:08 TheJacobTaylor

对不起编辑器（或我）的jacob在编写时有点混乱。 PK是一个整数自动增量字段。 varchar50不应该在该行上。不知怎的，它被错误地放置了，我很快就错过了它。 – corymathews 2010-02-18 19:35:56

Gotcha。 32位与100字节有点不同。我认为从速度角度来看，整数比较是单个CPU指令。字符串比较通常是多个（每个字符至少一个）。虽然他们可以同时处理，但我不知道他们这样做。 – TheJacobTaylor 2010-02-19 05:14:36

因为你的FK不能被强制执行（因为它是根据类型的变体）的数据库约束，我会认真考虑重新评估你的设计中使用链接表，其中每个链接表包括两个FK列，一个到实体的PK，一个到6个表中的一个的PK。

虽然这看起来有点过分，但它使许多事情变得更简单，添加新的链接表并不比调整新的FK类型更复杂。另外，它更容易扩展到一个实体需要比单个表格更多的1-1关系，或者需要与其他6个实体有多个1-1关系的情况。

在不断变化的，FK情况下，你可以失去数据库一致性，可以忽略对类型代码过滤器联接到错误的实体等

我要补充一点，链接表的另一个巨大的好处是，您可以链接到具有不同数据类型键（int，自然键等）的表格，而无需添加超顺序键或将键存储在容易出现问题的varchar或类似的解决方法中。

来源

2010-02-18 21:40:01

或者如果你不使用或不能链接表（这是我同意的想法），那么你需要一个触发器来保持数据的完整性，因为你不能将一个字段设置为FK到6个不同的表。 – HLGEM 2010-02-18 21:49:47

是否需要单个表的原因是，您希望确保当六个父表引用保证为相同实例的子行的给定实例？这是经典的“多亲”问题。您可能遇到的一个例子是地址或电话号码与多个人/联系人表。

我能想到几个选项：

选择1：每个父表的链接表。这将是Hoyle架构。所以，像这样：

Create Table MyTable(
        id int not null Primary Key Clustered 
        , info1 varchar(50) null 
        , info2 varchar(50) null 
        , info3 varchar(50) null 
        ) 

Create Table LinkTable1(
         MyTableId int not null 
         , ParentTable1Id int not null 
         , Constraint PK_LinkTable1 Primary Key Clustered(MyTableId, ParentTable1Id) 
         , Constraint FK_LinkTable1_ParentTable1 
          Foreign Key (MyTableId) 
          References MyTable (Id) 
         , Constraint FK_LinkTable1_ParentTable1 
          Foreign Key (ParentTable1Id) 
          References ParentTable1 (Id) 
         ) 
... 
Create Table LinkTable2...LinkTable3

选择2.如果你知道，你永远不会有超过说的六个表，并愿意接受一些非规范化和设计的fugly，你可以增加6个外键的主表。这样可以避免填充一堆链接表的问题，并确保正确的引用完整性。但是，如果父母的数量增加，那么这种设计可能会很快失去控制。

如果您满足于您现有的设计，那么就字段大小而言，我会使用完整的表名称。坦率地说，char（3）和varchar（50）甚至varchar（128）之间的性能差异对于您可能放入表中的数据量而言可以忽略不计。如果你真的认为你将拥有数百万行，那么我会强烈考虑链接表的选项。

如果您想保持您的设计并希望获得最佳性能，那么我将使用带有外键的tinyint指向包含带tinyint主键的六个表的列表的表。这可以防止数字变得“魔术”，并确保您缩小父表的列表。当然，它仍然不能防止孤立的记录。在这个设计中，你必须使用触发器来做到这一点。

来源

2010-02-19 05:31:31 Thomas

您能提供一个链接或更多关于“Hoyle架构”的细节描述吗？除此之外，我找不到其他说明。 – StingyJack 2014-07-30 15:47:48

性能 - 诠释与Char（3）

回答

相关问题