Any*_*are 3 normalization database-design
我的问题由三部分组成：
我什么时候才能确定我的数据库设计是完美的？
返回数据库设计更改某些问题（即添加新列、删除列、更改数据类型、添加新表等）是否被认为是不好的做法还是正常？
有没有只是在训练的任何网站或书籍ERD和normalization？我想要大量带有推荐答案的示例、实践和案例研究，以加强我在数据库设计方面的技能并避免我所做的糟糕的数据库设计。
注意：我不需要书籍来解释这些概念，我需要的是实践、示例和案例研究以及推荐答案。
1) 什么时候确定你的数据库设计是完美的？
您的设计永远不会完美，因为业务逻辑和数据量总是在变化。完美很难定义 我见过部署效果很好的系统，但在添加几年数据后性能很差。一些应用程序开发人员将数据库视为黑匣子的令人遗憾的趋势意味着一些数据库部署的关键表缺少主键或索引。对 CIO 来说是完美的，因为他们按时和按预算交付了应用程序，这对于必须处理问题的开发人员/DBA 来说可能是一件痛苦的事情。
以下是一些我会寻找的指标，它们表明您的设计已准备就绪
a) 广泛使用主键、唯一键、外键、索引，在较大的表上更是如此（我只提到这一点，因为我看过商业缺少此的产品)
b) 应用程序逻辑在数据库中使用约束和默认值尽可能地重复。您无法捕获所有内容，但只要知道条目总会有价值就可以让您高枕无忧。
c) 测试，测试，再测试：从用户角度测试数据输入，从想要概览的经理角度测试，从想要查看趋势的分析师角度测试如果你发现自己加入了需要全表扫描的9个大表为了找出分配给用户的工作，您可能需要重新检查一下。并非一切都可以简单，但要满足用户需求的过度复杂性就会带来麻烦。
d) 做一些关于如何扩展和不扩展数据库的白日梦。如果我需要为一个工作单元添加一个新属性，这有多难？可以不改变表来完成吗？如果你被要求添加一个新类型的工作有多难。（工作可以是产品、交易、案例）
e) 人和组织为我提供工作时间。创建、编辑、删除重复和报告它们有多容易？
f) 您支持多少种用户语言？需要什么字符集。例如，如果您打算支持英语和西班牙语，如果必须扩展设计以涵盖法语和意大利语，会发生什么情况？
2）返回到数据库设计来更改某些问题（例如添加新列，删除列或更改数据类型或添加新表或......）是否被认为是一种不好的做法还是正常？
我会说对于业务逻辑频繁更改或正在添加最终用户需求的应用程序来说这是正常的。