我以前创建过很多数据库，但我从未将两个表链接在一起。我试过环顾四周，但找不到为什么需要将两个或多个表链接在一起。
这里有一个很好的教程，介绍了数据库关系，但没有解释为什么需要它们。他只是简单地说他们是。
它们真的有必要吗？我知道（在他的示例中）所有订单都有一个客户，因此可以将订单表链接到客户表，但我只是不明白为什么这绝对是必要的。我可以（并且已经）创建了购物车和其他可以正常工作的复杂数据库，而无需创建任何表关系。
我刚刚开始为一个具有相当大和复杂数据库的新项目使用MySQL Workbench v6.0，所以我想知道创建没有关系的整个项目是否会丢失任何东西？
注意：如果这个问题太笼统或离题，请告诉我，我会改变它。我知道关于这个话题可以说很多，所以我真的只是想知道我是否因为不使用关系而对任何安全问题或重大性能问题敞开心扉。请具体回答；“是的，您正在向性能问题敞开大门”是无用的，对我自己没有帮助，也对以后查看此线程的其他人没有帮助。请在您的回复中包含详细信息和细节。
先感谢您！
正如 Sam D 在评论中指出的那样，可以写整本书来介绍数据库设计以及为什么拥有具有关系的表会很有意义。
也就是说，从理论上讲，只需将所有内容放在同一张表中，您就绝对不会失去表达/计算能力。反对这样做的主要论据可能涉及可能出现的性能和维护问题。
答案围绕粒度、空间消耗、速度和细节展开。
本质上不同类型的数据将比其他数据更细化，因为项目总是可以汇总到更大的保护伞中。对于连锁店，销售的商品可以汇总到交易中，交易可以汇总到注册批次，注册批次可以汇总到商店销售额，商店销售额可以汇总到公司销售额。那么这两个选项是：
在第一种情况下，会有很多冗余数据，因为在 430 个位置 3 出售的每件商品都有商店、日期、批次、交易和商品信息。当您可以很容易地为它们的独特目的创建单独的表时，这些冗余数据会占用大量空间。
在此示例中，假设每天有 1000 笔交易，从该商店售出的商品总计 100 万件。通过创建单独的表，您将拥有：
我敢肯定，您会问节省空间的来源......每条记录的详细信息。商店表有姓名、地址、电话等。登记表有号码、购买日期、协调经理等。交易有客户、日期、时间、金额、税金等。如果这些值在每条记录中重复单个表这将是大量的数据冗余，增加的空间消耗比仅将一个表中的字段（事务 id）链接到另一个表中的字段（项目 id）以显示这种关系要多得多。
此外，所消耗的空间量以及整个表的大小，都会反过来影响查询该数据的速度。通过保持表较小并利用关系标识符在它们之间进行链接，您可以大大增加响应时间。每次查询引擎需要查找一个值时，它都会遍历表直到找到它（这是一个严重的过度简化，但并非不正确），因此表越大越宽，查找时间就越长。这些问题并不存在于微不足道的数据量中，但对于处理数百万、数十亿、数万亿条记录（我为其中之一工作）的组织而言，将所有内容存储在一个表中会使应用程序无法使用。
关于这个主题有很多非常多的内容，但希望这能提供更多的见解。
简短的回答：在像 MySQL 这样的关系数据库中是的。检查这个关于参照完整性http://databases.about.com/cs/administration/g/refintegrity.htm
这并不意味着您必须为您的项目使用关系数据库。事实上，趋势是使用非关系型数据库 (NoSQL)，例如 MongoDB，以实现相同的结果并具有更好的性能。有关 RDBMS 与 NoSQL 的更多信息http://www.zdnet.com/rdbms-vs-nosql-how-do-you-pick-7000020803/
我认为通过这个例子你会更好地理解：
让我们想要创建在线商店。我们至少有用户、付款和事件（有关用户导航或其他操作的页面的事件）。在这种情况下，我们希望以安全和相关的方式将用户与付款联系起来。我们不希望付款丢失或分配给其他用户。所以我们可以使用像 MySQL 这样的 RDBMS 来创建表 Users 和 Payments 并用适当的外键链接它们。然而，对于这些事件，每个用户（可能是数百万）我们将有很多事件，我们需要快速跟踪它们而不杀死关系数据库。在这种情况下，像 MongoDB 这样的 No-SQL 数据库是完全有意义的。
总而言之，可以使用 SQL 和 NO-SQL 的混合，但如果您使用其中一种、另一种或两种解决方案，请正确执行。