我确信在这方面有成千上万的DBA有设计优化数据库的经验 我会要求他们分享他们的一些经验：
答案 0 :(得分：4)
您的问题非常广泛 - 我的答案也是如此（这是针对典型的业务线应用程序 - 而不是数据仓库或决策支持系统）：
使用相应的数据类型 - 不要在字符串字段中存储日期 - 不要在字符串字段中存储数值（我之前已经看过它们！ ）;如果你的字符串是60-100个字符 - 不要在SQL Server中使用VARCHAR(MAX)（2 GB）.....如果你有少于5个字符的固定长度字符串（例如代码） - 使用{{1不是CHAR(x)等等......
规范化您的数据 - 尝试实现第三种正常形式 - 然后然后在需要且适当的情况下进行非规范化。但首先设计到3NF标准化水平。这也意味着：每个表都有一个明确定义的主键。
在适当的地方使用约束 - 子表和父表之间的外键关系，对单个列中允许的值的约束以及唯一性约束。
非常认真地对待查询访问 - 将查询哪些表格如何？考虑可能的指数 - 但不要过度！太多指数可能比没有指数更糟糕。找到平衡点。
另外还有一些供应商特定的优化/待办事项。
即。在SQL Server中，我会：
总是在外键字段上放置一个索引 - 它有助于加入JOIN并加快确保参照完整性
经常将大型blob字段（VARCHAR(x)，VARCHAR(MAX)）移动到单独的表中，并将它们链接到“基础”表。这样，如果您正在使用例如一个ORM，你不会一直把所有那些巨大的字节加载到内存中。
Paul Litwin撰写的这篇文章Fundamentals of Relational Database Design总结得非常好。
答案 1 :(得分：2)
我认为第一条规则是One Database不能做任何事情。它无法针对读取和写入密集型操作进行优化。因此，您可以拥有多个具有特定用途的数据库。
操作数据库
对于实际日常运行更新，读取，写入或应用程序最终用户访问的系统。这应该在3NF，但是如果需要改进慢查询，你可以打破NF和denormalise某些字段
报告数据库
此数据库（数据仓库）针对仅READ操作进行了优化。它将是denomoralised，通常为star schema.
暂存数据库
如果您需要多个应用程序来访问您的数据。您可以创建一个临时数据库，其中包含操作数据库中所有数据的副本，主要区别在于此DB不应具有任何INDEXES或许多约束，触发器等，因为它们都会降低INSERTS（写入）的速度。此DB仅用作临时存储以快速提取所有生产数据，但其他应用程序不应直接与此DB一起使用。其他应用程序应该从中提取所需的数据并将其放入自己的格式中。例如，将数据从暂存复制到报告/数据仓库。其主要目的是减少运营数据库的负担。
因此，关键在于您的操作数据库，您应该了解Database normalization，如果您想要进行大量插入操作，请注意您的字段上的触发器和索引，因为它们会降低插入速度。另外，请查看NOSQL数据库，以获得更好的性能。