这是一个好的数据库设计概念吗？答案

【问题标题】：Is this an OK Database design concept?这是一个好的数据库设计概念吗？
【发布时间】：2010-09-24 02:47:24
【问题描述】：

EDIT1：试图通过重命名表及其关系来解决问题。 EDIT2：请不要查看我在三个数据库表中保存的数据类型。他们是在飞行中组成的。它们不是我的真实世界场景（不，我不能谈论我的真实世界数据......事实上，目前它是 1 个父母和 6 个孩子）。请忽略什么类型的数据，只看需要一些数据的事实。 EDIT3：这两个 FK 是 0 或 1 对 1 的关系。不是 0 到很多。不是 1 对 1。我试图避免 0 或 1 对 1 关系与 1 对 1 关系，所以我不需要 OUTER JOIN 而是有 INNER JOIN。

问题：我需要知道建议的数据库设计是好/坏/蹩脚/等等。

问题：今天我尝试制作一个索引视图，但失败了，因为我的表有外部连接。叹。所以我想知道我是否可以把它改成如下设计：

三个表。
table_User 在 table_Address 上有一个 FK
table_User 在 table_Vehicle 上有一个 FK
等等..

表 B 和 C（现在有点像查找表）有..

Id INT IDENTITY PK
描述 NVARCHAR(100) NULLABLE

注意到可以为空的了吗？这样，table_User 中的某些内容在 table_Address 中不存在......该字段为空（因为内部连接）。

之前，我做了一个 LEFT OUTER JOIN，所以如果 table_b 中没有数据，我会得到每个字段的结果为空。

我会在这里抛出一些数据示例......

表用户

ID：1，姓名：Fred，AddressID：1（NULL）
ID：2，姓名：Joe，AddressID：2（1 smith street.....）
ID：3，姓名：Jane，AddressID：2（1 smith street.....）

表格地址

ID：1，描述 = NULL
ID：2，描述 = 1 smith street

等等

那么我终于可以将这一切放入索引视图中。（我的现实生活场景大约有 8 张桌子）。

注意：DB 是 Microsoft Sql Server 2008，但这可能适用于任何 DB。

Q1：这个设计看起来还可以吗？

Q2：所以我在这里做的是对数据进行规范化，对吗？通过保持内部连接在一起。

Q3：最后，如果这是一个好的方法.. 我是否也可以通过一些唯一的约束或键或索引或什么来确保表中的数据是唯一的（例如街道地址）（我'我不确定正确的术语）。

感谢大师！

【问题讨论】：

应该可以创建一个包含任何类型连接的索引视图。您使用哪个数据库？您可以使用 DDL 以及视图的创建语句和错误消息来扩展您的问题吗？
DDL？我的数据库是 MS Sql 2008，它不允许外部连接。最后，我没有提出任何查询或表格......我只是在绘制设计图片并思考架构。
正如其他人所说，恐怕问题不是很清楚。用户和地址之间存在什么样的关系 - N:P？为什么您的示例中有一个“虚拟”地址行？也许您可以发布一个示例，说明您希望从视图/查询中得到什么，涵盖所有这些情况。
人们通常拥有不止一个地址和不止一辆车。我认为您需要用于用户地址和用户车辆的联结表。

标签： database-design normalization

【解决方案1】：

我个人会对这种设计说“不”。原因：

（可能不适用）试图保持地址字段标准化意味着您需要处理此字段以确保避免意外重复。 IE。您必须确保用户以正确的格式输入地址（否则 '1 mystreet' 也可以输入为 '1, mystreet' 或其他 - 需要检查这一点以避免重复，否则规范化是没有用的）
即使您找到了规范化的理由（即为地址保留单独的表），“虚拟”地址的概念对我来说还是很陌生。为什么不使用可为空的 FK 关系，即在父用户表中存储一个 NULL 地址 ID，而不是在其中放置一个虚拟 ID。

【讨论】：

我之所以不建议可以为空的 FK 关系是因为我试图避免 LEFT OUTER JOIN 关系。
嗯？为什么要避免 LEFT OUTER JOIN 关系？您可以拥有带有可为空字段的表，并且永远不要使用 LEFT OUTER JOIN。一个与另一个无关。

【解决方案2】：

所以您基本上是在表 B 和 C 中添加虚假记录，以使行数与 A 中的行数相同？如果我是你，我不会这样做，因为如果你的数据集很大，那么你会在没有任何实际需要的情况下增加行数，而且你也面临着不一致的风险（你的布局很大程度上取决于你拥有插入这些虚假记录）。除此之外，你想用索引视图实现什么？性能增益？您不是在编写您正在使用的 DBMS，但根据我在 MSSQL 方面的经验，这不会给您带来很多好处，因为只要您在表 A、B 和 C 中有适当的索引，服务器就可以使用即使没有索引视图，他们也可以构建良好的查询计划。

【讨论】：

正确。这是我的问题。将一个带有 5 或 6 个其他 FK 的“父”表分别放在一个单独的表中，并且这些表中的每一个都是可选的（因此是外连接）.. 它正在扼杀我的查询 :( 所以我想知道是否可以进行内连接（以拥有更多数据为代价）或非规范化。
我宁愿进行一些索引优化，但仍然在基础表上工作。我真的不认为索引视图会给你带来很多改进，但我承认从左连接切换到内连接可以给你一些 - 前提是你没有很多 NULL（所以很少有额外的记录)

【解决方案3】：

一个非常令人困惑的问题，所以请查看数据库的规范化。第 3 范式（希望在英文中这样称呼）应该可以解决大部分问题。

快速提示：如果您有重复的数据，那么您需要一个单独的表，您可以通过外键在第一个表中引用该表。其他一切都只是查询。

【讨论】：

我试过做 3NF，但我不认为我能到达那里（甚至是 1NF），因为有些表有可为空的字段，如果我记得我的数据库，1NF 通常表示没有字段可以为空很久以前的东西。
我不记得 1NF 的先决条件是没有字段可以为空。请引用参考文献

【解决方案4】：

我觉得您的问题令人困惑，但也许我可以提供一点帮助。

首先，表没有连接，查询有。您不会创建一个连接到另一个表的表。只有 2 个表可能相关，您可以使用连接查询这些表。

我建议您阅读有关数据库规范化的内容。维基百科有一篇很棒的文章：http://en.wikipedia.org/wiki/Database_normalization

关于您目前的情况，我不确定您要做什么。如果该地址在不同的行中重复，则具有地址的 ID 似乎没问题。然而，需要几个“地址表”似乎很奇怪。设计时要记住的最重要的事情是： - 在每个表中都有一个正确的主键，因此您可以正确连接表。 - 除非你有非常好的理由，否则不要重复数据。不过我还是推荐上一篇。

希望有帮助！ :)

【讨论】：

我完全同意表不进行联接.. 但我试图简化问题以突出显示如果我进行查询我将如何加入表。结果适得其反。我已更新问题以帮助澄清我的问题。