Question

我有一张桌子，正在讨论两种不同的信息存储方式。它有这样的结构

int id

int FK_id

varchar（50）info1

varchar（50）info2

varchar（50）info3

int forTable 或 char（3）forTable

FK_id可以是6个表之一的外键，所以我需要另一个字段来确定它的表。

我看到两个解决方案：

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

我想知道是否有人知道一个人是否会比另一个更有利于速度，或者如果使用char（3）会有任何重大问题

注意：我将为该字段的6个不同值中的每一个创建一个索引视图。该表将包含~30k行，需要与更大的表

连接

Answer 1

在这种情况下，除了校对开销（A vs a vs ä va à）

之外，它可能无关紧要

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

3字节+整理与4字节数字？在重要之前，您需要数十亿行或运行中等规模的国家......

Answer 2

您是否考虑过使用TinyInt？只需要一个字节来存储它的值。 TinyInt的值范围介于0到255之间。

Answer 3

是否需要单个表，以确保当六个父表引用保证为同一实例的子行的给定实例时？这是典型的“多父”问题。您可能遇到此问题的一个示例是带有多个人/联系人表的地址或电话号码。

我可以想到几个选项：

选择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.如果你知道自己永远不会说六张牌并且愿意接受一些非规范化和一个简洁的设计，你可以在主表中添加六个外键。这避免了填充一堆链接表并确保适当的引用完整性的问题。但是，如果父母的人数增加，那么这种设计很快就会失控。

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

如果你想继续使用你的设计并希望获得最大的性能，那么我会使用带有外键的tinyint到一个包含带有tinyint主键的六个表的列表的表。这可以防止数字变得“神奇”，并确保缩小父表列表的范围。当然，它仍然不能阻止孤立的记录。在此设计中，您必须使用触发器来执行此操作。

Answer 4

因为你的FK不能通过数据库约束来强制执行（因为它是一种变体，取决于类型），我强烈考虑重新评估你的设计以使用链接表，其中每个链接表包括两个FK列，一个到PK实体和6个表之一的PK。

虽然这似乎有些过分，但它使得很多事情变得更简单，添加新的链接表并不比容纳新的FK类型复杂。此外，它更容易扩展到实体需要与单个表的关系超过1-1的情况，或者需要与其他6个实体的多个1-1关系。

在变化的FK场景中，您可能会失去数据库一致性，您可以通过忽略对类型代码进行过滤等来加入错误的实体。

我应该补充一点，链接表的另一个巨大好处是，您可以链接到具有不同数据类型（整数，自然键等）的键的表，而无需添加代理键或将密钥存储在varchar或类似物中容易出问题的变通方法。

Answer 5

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

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

Answer 6

首先，一个不是全局唯一的50个字符的ID听起来有点可怕。 ID有什么意义吗？如果没有，您可以轻松地在更小的空间内获得GUID。就个人而言，我非常喜欢尽可能使人类可读的东西。我会，并且已经将全名放在图表中，直到我需要做其他事情。我的偏好是为每个可能的相关表格建立链接表。

除非你说的是真正大规模的，否则你最好减少ID的大小并为表名添加更多的字符。对于非常大的规模，我会减小ID的大小并使用整数。

雅各

表演 - 国际对战与查尔（3）

6 个答案: