是否可以创建列大小不匹配的外键

时间:2013-08-22 13:38:25

标签: mysql sql oracle foreign-keys

我发现了我认为Oracle中奇怪的行为

可以创建列大小与引用列大小不匹配的外键,这似乎不正确。当然,数据库应该强制匹配列大小,我在这里遗漏了什么吗?

我很确定MySQL不允许这个

SQL> create table parent(col1 varchar2(255) primary key);
Table created.
SQL> create table child(col1 varchar2(20) primary key, constraint col1_fk foreign key (col1)
references parent(col1));
Table created.

2 个答案:

答案 0 :(得分:8)

虽然FK在数据类型和大小方面都匹配当然是首选,但有时候它可能不实用(或者甚至是个好主意)。在上面的例子中,PK更大,因此这不会导致第二个表的数据输入出现问题,因为它们只会输入50个字符或更少的字符(在子表格字段较大的情况下执行反向操作会毫无意义sa你永远不能输入比PK更大的数据。根据第一个表中的数据,实际上可能会阻止您从原始表中输入您不想要FK的值。但是,如果要链接到长度为118个字符的PK记录,则会出现问题。

让我们看看一个表格设计得很糟糕而且字段太大而且历史上我们想要保留的一些数据,但不会链接到任何新表格的情况。也许我们现在通过触发器或约束或通过应用程序强制执行较小的大小。在新的子表中,我们只希望能够加入与当前需求匹配的记录,并且永远不需要加入较旧的较长记录。在这种情况下,将第二个表设计为仅采用较小的长度是一个好主意。

在某些情况下,初始表可能包含不同类型的数据(比如键值存储),子表可能只想链接到一种类型,并且该类型的长度小于父表中允许的长度考虑到不同的类型。再次使用较小的长度将是一件好事。

我认为像这样的场景是允许它的原因。但是,仅仅因为允许某些事情并不是最佳做法。如果我正在创建一个表,并且我没有具体的理由为什么该字段应该是不同的,那么我将创建它们相同。它就像游标,它们存在于特定用例中,但它们可以用于其他不是最佳选择的用户。数据库设计涉及了解如何确定最佳方法,而不仅仅依赖于某些事情是可能的事实。

答案 1 :(得分:0)

主键列大小较高,因此理论上它不应该产生任何问题。

但是当条件是主键大小较小的其他方式时,它会引起麻烦。

但最好的方法应该是相同的数据类型和大小。