设计数据库的正确方法

Question

我开始了我的第一个设计ERD, logical and physical diagrams的MySQL项目。

我的一位朋友正在制作和我一样的项目。我开始制定ERD并正常化，从而开始制定我的数据库计划。

但是，他使用关系数据库图表，他在设计接口和其他部件之前首先进行ERD。例如，他只将“堆栈”写入列数字，而不是制作“帮助表”。他说最好先制作接口，然后制作ERD。

我们哪一个在你看来更好的计划？

Answer 1

有人可以，也有很多人写了一本书。

不过来概括我一般会做的是

1. 分析数据，并减少它归结为是第三范式。这应该是完美的公式化。
2. 鉴于数据可能的业务使用情况，决定是否以及在哪里数据应该非规范化。通常大多数数据库将在绝大多数数据库中处于第三正常状态，但有一些重要的例外。这部分是经验和工艺进来的地方。
3. 根据上述内容创建可能需要的任何附加索引，或者修改现有的主索引（应该在阶段1中分配）。
4. 根据需要为用户访问创建视图。您需要的数量可能会有所不同（如在简单的嵌入式应用程序中）到很多（因为不允许直接访问表中的数据）。
5. 创建您需要的任何程序，并可能触发（通常最好避免但适合审计目的）。

当然，在实践中这个过程是相当多的反复，但是从数据到接口的一般设计路径成立。在设计数据库时也是一个好主意，记住您稍后要改变它，并尽可能地尝试做出相当简单的任务。

Answer 2

我不确定你的意思是“接口和操作”，但是你设计模式的方式是正确的 - 做一个ERD并正确地标准化。很多人刚刚起步时，都会在设计上采取捷径，以便使模式适合当前的查询技能水平。

例如，与其创建电话号码表并将这些电话号码映射到“客户”表，它们可能只是坚持在名为Phone1 Phone2 Phone3的列中。当设计你的查询时，这可能是死亡之吻。

所以我的建议...创建规范化的数据模型与ERDs。然后阅读VIEWs和用户定义的函数，以便在希望查询它的人员需要时“扁平化”您的模式。对不起，一般的答案，但这是一个普遍的问题...