我想知道我是否可以利用经验丰富的数据库设计人员。我在构建数据库方面不是很有经验，我有一个项目要在设定的时间内（几个月）完成。要求是将其构建为第三范式。
我只是想知道最好的开始方式是什么？我是否应该继续构建一些可行的东西（尝试尽可能高效），然后返回并重构任何可以改进的部分，或者是否有一些方法可以遵循以确保从一开始就达到一定程度的规范化？
【问题讨论】：
标签： database database-design normalization
不要为了稍后返回并对其进行规范化而构建数据库。数据库不像应用程序代码那样容易重构一件事，另一方面，您已经要求遵循第三范式，所以从一开始就这样做，它将少得多的工作，最终成为一个更好的产品。在第三范式中没有纠正数据库设计的捷径。在开始设计之前，只需清楚地了解它是什么。
如果您不熟悉第三范式中的数据库设计，请花几天时间阅读一下数据库设计。然后花一天左右的时间阅读有关性能调优的数据库 - 从一开始就设计一个性能良好的数据库将为您节省大量时间。一旦您知道要做什么和要避免什么，就不会比设计一个性能不佳的数据库花费更长的时间。所以我给你的第一个建议是在开始之前买几本厚重的书并深入阅读。您花在这方面的时间将得到很好的回报，让您有能力在项目的其余部分做得更好。
【讨论】：
您肯定会在此数据库层之上编写许多层（DAL、BAL、UI）。较低级别的每个更改都会向上冒泡，并导致比仅在数据库层进行更多的返工。
我认为您应该完成所有设计并让数据库达到所需/需要的最佳规范化，以便在一开始就保存您的数据而不会出现异常。
【讨论】：
与前端编程不同，重构数据库结构，一旦使用，不仅痛苦，而且不切实际。
我强烈建议您提前了解后端的结构。好消息是第三范式通常并不难实现。事实上，一旦你变得有点实践，用这些术语来思考数据几乎成为第二天性。
第三范式本质上表明表中单个记录的每个组件对于该记录的键都是唯一的。考虑：
tblPerson： 个人身份PK 姓 名 中间名字 出生日期 社会保障号 收入来源 收入金额
上面定义的表格不是第三范式，因为收入来源对于表格中每个人的发生率并不是唯一的，实际上在该人的一生中可能会发生变化。取而代之的是，将上述结构（过于简单化）如下：
tblPerson 个人身份PK 姓 名 中间名字 出生日期 社保号
tblPersonIncome 个人收入ID PK PersonID FK tblPerson IncomeSourceID FK tblIncomeSource 收入金额 截止日期
tblIncomeSource 收入来源ID 收入来源
请注意，有些人会争论我使用上面的自动递增 ID 字段 - 虽然这些不违反第 3 范式，但它们也没有使用自然键。
如果您的后端从跳转正确规范化，那么添加或扩展您的实体在未来会更容易完成，并且对您在添加之前创建的任何前端的影响要小得多。
无论如何，请在后端前端进行正确设计，否则一旦开始滚动并需要稍后实施结构更改，痛苦就会很严重。否则就有点像为你的新房子打地基，并计划在以后建造它时改变平面图以满足你的需要。
【讨论】：