在设计数据库时要记住哪些重要事项?
我不想限制你对我的需求的回答,因为我相信其他人也可以从你的见解中受益.但我正在为多客户社区驱动的网站规划一个内容管理系统.
"正常化直到它疼痛;去标准化直到它起作用."
(假设OLTP)
数据结构的规范化.(性能去标准化通常可在以后需要时进行)
http://en.wikipedia.org/wiki/Database_normalization
预先建立一致的命名标准.从长远来看,它将节省几分钟不必要的思考.(这可能看起来很讽刺,但我很认真.)
除非它非常普遍,否则不要缩写任何东西.不要将数据库变成牌照消息猜测游戏.一年之后变得不明显的事情令人惊讶.
请确保您使用的限制(CHECK
,NOT NULL
,FOREIGN KEY
,PRIMARY KEY
,和DEFAULT
),以保证只有正确的数据被存储在数据库中的首位.您可以随时购买更快的硬件,但无法购买更多正确的数据.
试着想象一下你将对它进行预编码的SQL查询.
这很重要,因为你会做很多!
我会记住一些事情.确保每个表都有一种唯一识别记录的方法(这样可以节省数小时的痛苦).标准化但不加入大型多列自然键,除非您希望整个过程变慢.请改用父表中自动生成的数字键.
是的,考虑一下您需要运行的查询和报告的类型.考虑可扩展性.您可能看起来在订单表中不需要超过10个产品列,但在需要时会发生什么情况11.最好有订单表和订单明细表.
确保将所有数据完整性规则合并到数据库中.并非所有数据都发生在用户界面上,我不得不尝试修复太多乱糟糟的数据库,因为设计人员认为将所有规则放在GUI中都可以.
在设计时要考虑的最关键的事情首先是如何确保数据完整性(如果数据毫无意义,那么数据库是无用的),以及如何确保性能.除非您想要性能不佳,否则不要使用对象模型来设计关系数据库.
下一个最重要的是数据保护和安全性.用户永远不应该直接访问数据库表.如果您的设计需要动态SQL,则必须具有该访问权限.从SQL注入攻击等潜在黑客攻击的角度来看,这很糟糕,但更重要的是,它会为内部人员欺诈行为打开数据库.是否存在需要加密数据的字段(信用卡信息,密码和社会安全号码是永远不应以未加密方式存储的项目).您打算如何做到这一点?您计划如何审核解密,以确保人们在不需要查看数据时不解密.您是否必须经历合法的箍(HIPPA和萨班斯·奥克斯利的想法)?