database - 在设计应用程序数据库时要牢记的一般准则和最佳做法是什么？

Question

我的问题是关于数据库建模。我试着在其他数据库设计问题中寻找这个问题，但是没有找到，所以这里要问：
在为应用程序设计数据库时，需要记住哪些一般准则和最佳实践？
关于数据库设计概念的最佳资源/书籍/大学讲座有哪些？
谢谢。

Answer 1

只是一些我从经验中学到的东西（我相信有些人会不同意，但我已经查询、设计和编程数据库30多年了，并亲眼目睹了愚蠢设计的影响）：
在所有的数据库设计中，有三件重要的事情需要考虑：数据完整性（没有这一点，实际上就没有数据）、安全性和性能。所有其他的考虑都要放在这三个问题的后面。
如果没有唯一标识记录的方法，就不要创建表。
真正起主键作用的真正自然键真的很少，如果您无法控制它是否会更改，请不要将其用作主键（您真的不想通过27个子表更改公司名称，是吗？）。请改用代理项密钥。如果可以使用唯一的组合键，则使用代理项键并不能免除设置唯一索引的需要。如果可以确定使用唯一组合的方式，请始终设置这些索引。重复记录是应用程序存在的祸根。这似乎很明显，但从来没有考虑过名称是一个关键字段，名称不是，也永远不会是唯一的。
不要使用guid作为主键，因为它会破坏性能。如果需要复制的guid，还可以考虑使用int或big int主键。
除非事先知道要更改数据库后端，否则不要将其设计为要更改数据库后端。实际上，性能优化的所有好技术都是数据库特有的，不损害您自己调整数据库的能力，以满足不存在的需求。
避免使用值实体表结构。他们很难质疑。
在数据库设计中添加确保数据完整性所需的所有内容，如默认值、约束、触发器等，以避免出现无用的数据。不要依赖应用程序代码来执行此操作，否则您将感到抱歉。
其他人提到了规范化，我同意你必须完全理解这一点，即使你后来决定去规范化。
如果您想要任何类型的性能，请不要将视图堆叠在视图的顶部。我见过的每一个这样做的数据库最终都是一个巨大的性能问题。
考虑管理数据库所需的数据以及应用程序所需的数据。如果你要认真对待数据库，你需要了解数据库审计，你的数据库应该实现一些方法，找出谁做了什么改变，什么时候，旧数据是什么。如果有人第一次恶意更改数据或意外删除表中的所有记录，您将感谢我。
仔细考虑在设计时如何查询数据。它可以在设计上产生巨大的变化。
不要在一个字段中存储多个信息。将逗号分隔的列表放在一个字段中而不是添加一个相关的表可能看起来很酷，但这是一个非常糟糕的主意。
优雅常常是数据库性能的敌人。每次选择表现胜过优雅，你就不会出错。
避免在命名对象时使用数据库关键字。你的程序员会感谢你的。选择一个命名约定并始终使用它。如果一个字段在多个表中，请确保它是相同的名称（如果一个id字段在同一个表中有两个可能的外键，则例外情况是使用id字段名和前缀来标识sales_person_id和customer_person_id之间的差异），相同的数据类型和长度（如果适用于所有表）。马上纠正拼写错误，你真的不想在接下来的十年里记住表中的是拟人而不是拟人。
阅读数据库重构（在amazon上搜索一些好书）并考虑如何在设计中做到这一点。很少有数据库被设计成可重构的，能够重构对于能够修复由于考虑不周的设计或业务需求的更改而产生的数据库问题至关重要。
当您阅读、阅读有关性能优化的内容时，您将了解到在设计数据库时应避免的大量内容。
我相信还有更多，但这已经足够开始了。
我还想补充一点。不要将数据库设计为数据输入应用程序页是最关键的。即使在事务数据库中，查询数据的频率也比写入数据的频率高。好好想想从数据库中获取数据有多容易（哦，这就是为什么eav模型如此糟糕！）以及设计对报告的影响。这一点尤其重要，因为我经常看到，做报告的人不是设计数据库的人，也不是在项目中比创建数据项晚的报告任务的人。数据库不容易重构，在设计数据库时要考虑数据的整个生命周期。考虑一下将时间值存储为矩之类的事情，因为两年后，您无法通过将订购数量乘以产品表中的价格来确定订单的金额，因为这不是订购时的价格。报告需要这种类型的信息，但在设计做得不好的情况下，通常在编写报告时获取这种信息太晚了。当你一次处理一个记录的时候，那些工作正常的东西在你需要查看数千或数百万个记录的时候可能会成为一场灾难。并不是每个应用程序都要创建一个单独的报表数据库，所以请认真考虑这个问题。