在为应用程序设计数据库时要记住哪些一般准则和最佳实践？
数据库设计概念有哪些最好的资源/书籍/大学讲座？
谢谢.
我从经验中学到了一些东西(我肯定有些人会不同意,但我已经查询和设计和编程数据库已有30年了,并且已经看到了愚蠢设计的影响近似和个人化)：在所有数据库设计中都要考虑三个关键事项 – 数据完整性(没有这个基本上没有数据),安全性和性能.所有其他考虑因素都落后于这三个因素.
永远不要创建一个没有唯一标识记录的方法的表.
真的很少有真正的自然键真正作为主键使用,如果你无法控制它是否会改变,不要将它用作主键(你真的不想改变公司名称)你有27张儿童桌吗？).请改用代理键.如果您可以使用唯一的复合键,则使用代理键不会使您无需设置唯一索引.如果可以确定获得唯一复合的方法,请始终设置这些索引.重复记录是应用程序存在的祸根.这似乎是显而易见的,但永远不要将名称视为关键字段,名称不是,也永远不会是唯一的.
不要使用GUID作为主键,因为它可能会降低性能.如果你需要一个guid进行复制,也可以考虑使用int或big int主键.
不要设计好像要更改数据库后端,除非你事先知道你会这样做.实际上,性能调优的所有优秀技术都是特定于数据库的,不会损害您自己根据不存在的要求调整数据库的能力.
避免使用价值实体表结构.他们很难查询.
添加所需的所有内容以确保数据完整性到数据库设计中,默认值,约束,触发器等内容是必要的,以避免产生无用的数据.不要依赖应用程序代码来执行此操作,否则您会感到抱歉.
其他人提到了规范化,我同意你必须彻底理解这一点,即使你后来决定非规范化.
如果您想要任何类型的性能,请不要在视图顶部堆叠视图.我见过的每个数据库都是一个巨大的性能问题.
考虑管理数据库所需的数据以及应用程序需要的数据.如果您要认真对待数据库,则需要了解数据库审计,并且您的数据库应该实现方法,以找出谁做出了哪些更改,以及何时以及旧数据是什么.第一次有人恶意更改数据或有人意外删除表中的所有记录时,你会感谢我.
真的想一想在设计时如何查询数据.它可以在设计上产生巨大的差异.
不要在字段中存储多条信息.将逗号分隔的列表放入一个字段而不是添加相关表可能看起来很酷,但这是一个非常糟糕的主意.
优雅往往是数据库性能的敌人.每次选择性能优于优雅,你不会出错.
避免在对象命名中使用数据库关键字.你的程序员会感谢你.选择一个命名约定并始终使用它保持一致.如果一个字段在多个表中,请确保它是相同的名称(例如,如果一个id字段在同一个表中有两个可能的外键,则使用id字段名称和一个前缀来标识说Sales_person_id和Customer_person_id之间的差异),相同的数据类型和长度,如果适用于所有这些.马上修复拼写错误,你真的不想在接下来的十年中记住,在表格中它是persnoid而不是personid.
阅读有关数据库重构的信息(在亚马逊上搜索一些好书),并考虑如何在设计中实现这一点.很少有数据库被设计为重构,并且能够这样做对于能够修复由经过深思熟虑的设计或业务需求变化引起的数据库问题至关重要.
在阅读时,阅读有关性能调优的内容,您将学到很多关于在设计数据库时应避免的内容.
我相信还有更多,但这足以开始.
我想添加一个额外的东西.不要像设置数据输入应用程序页面那样设计数据库.即使在事务数据库中,也经常查询数据而不是写入数据.真的想想将数据从数据库中取出是多么容易(哦,这就是为什么EAV模型如此糟糕！)以及设计对报告的影响.这是非常关键的,因为我经常看到进行报告的人不是设计数据库的人,或者报告任务在项目的后期而不是创建数据条目.数据库不容易重构,在设计数据库时要考虑数据的整个生命周期.考虑存储时间价值的事情,因为两年后订单的数量乘以产品表中价格的数量,因为这不是订单时的价格.如果信息报告需要这种类型,但是当设计执行不当时,报告编写时通常为时已晚.当您需要查看数千或数百万条记录时,一次处理一条记录时工作正常的东西可能会很麻烦.并非每个应用程序都会创建单独的报告数据库,因此请真正考虑这一点.