我正在研究我公司用于创建调查的旧网络应用程序。我通过mysql命令提示符查看了数据库模式，并认为这些表看起来非常可靠。虽然我不是数据库专家，但我非常精通其背后的理论（在我的软件工程课程中学习了一些数据库设计课程）。
话虽这么说，我将create语句转储到一个SQL文件中并将它们导入MySQL Workbench，看到它们没有使用任何“实际”外键。它们会像使用FK一样存储另一个表的主键，但它们不会将其声明为一个。
因此，看看他们的数据库是如何设计的，就像我通过我所知道的那样（减去FK问题），我想知道可能背后的原因。这是一个懒惰编程的情况，还是通过编程方式进行所有错误检查可以获得一些性能提升？
如果你想要一个例子，他们基本上有调查，调查有一系列问题。一个问题是调查的一部分，所以它在一个专栏中保留了它的PK。这就是它，但他们到处使用它。
我很感激任何见解:)（我知道这个问题可能没有正确/错误的答案，但我正在寻找更多关于为什么他们会这样做的信息，因为这个系统自从我们以来一直很稳固开始使用它，所以我开始相信这些人知道他们在做什么）
答案 0 :(得分：12)
原始开发人员可能选择使用MyISAM或任何其他不支持外键约束的存储引擎。
答案 1 :(得分：4)
MySQL只支持在InnoDB表上定义实际的外键关系，也许你的是MyISAM，还是别的什么？
更重要的是，正确的列上已经定义了索引（因此持有另一个表的PK的列应该被索引）。这在MyISAM中也是可能的。
答案 2 :(得分：3)
作为一般要点;密钥加速读取（如果它们适用于读取发生它们帮助优化器）并减慢写入速度（因为它们会增加表的开销）。
在绝大多数情况下，读取和维护引用完整性的速度的提高超过了它们为写入添加的微小开销。
这种区别因缓存，镜像等而变得模糊，因为很多大型网站上的大量读取实际上都没有点击“实时”数据库 - 但除非您为亚马逊，Twitter等工作，否则这不是很相关。
答案 3 :(得分：2)
在uber大型数据库（Teradata支持的类型）上，您发现它们不使用外键。原因是表现。每次写入数据库时（通常在数据仓库中），您都需要检查表中所有fk的额外开销。如果你已经知道它是真的那么重要。
小型数据库上的良好设计只是意味着你将它们放入，但是通过将它们排除可以获得性能提升。
答案 4 :(得分：0)
您实际上不必使用外键。
如果您没有，数据可能会变得不一致，您将无法使用级联删除和更新。
如果您拥有它们，由于模式更改导致SQL语句中的错误，您可能会丢失一些用户数据。
有些人喜欢拥有它们，有些人更喜欢没有它们的生活。在任何一种情况下都没有真正的优势。
答案 5 :(得分：0)
这是一个真实的实例，我没有使用外键。
我需要一种方法来存储父子关系，其中孩子可能不存在，而孩子是抽象类。由于孩子可能是几种类型，我使用一个字段来命名孩子的类型，并使用一个字段列出孩子的id。该应用程序处理大部分逻辑。
我不确定这是否是最好的设计决定，但这是我在截止日期之前提出的最好的决定。到目前为止，它一直运作良好！