设计数据库时最重要的考虑因素是什么?

首先,最重要的是学习和理解业务领域。

1)您是否认为高交易率像繁忙的网站,或低使用率像一个小公司的人力资源系统

2)安全是否是一个大问题-您是否处理个人信息或财务数据。或者只是产品目录

3)您的用户会进行多次更新/插入,还是主要是只读的?

4)有多少用户,使用模式是什么(峰值负载或均匀分布)

5)您是否需要24x7、16x5或其他正常运行时间,24x7更难做到,因为您没有停机维护时间。

6)数据库的规模有多大?如果它真的很大,那么必须设计表来考虑这个和/或分区。

7)您需要查看具有热故障转移的企业集群,还是只查看正常的托管

8)数据库将如何管理,在大多数数据库项目中,95%的工作是为用户及其应用程序开发的,数据库管理被遗忘了。

9)数据库管理,以前包括备份、对其他系统的更改、与其他系统的集成、数据加载

10)实际数据加载和使用现有数据本身就是另一个大问题。

就这样开始吧

数据库是业务流程设计的辅助数据库,应该以直接和简单的方式清晰地支持业务流程。 您将从一个结构良好、干净的实体模型中获得比从索引中获得的收益多得多的好处。所以一旦你的过程被定义了,你就把它和有意义的关系尽可能清晰地划分成“实体”。一旦了解了实体,它们就会转换为数据库表。

要做的最重要的事情之一是不要进行总体架构。

为了给你一个有一些牙齿的答案,让我们以一个“车辆”实体为例。一辆车有多个轮子。您需要做出一个重要的决定,即车辆将安装多个车轮。您有两个选择-您可以将“车轮”设置为单独的实体,或者将“车轮数”设置为“车辆”实体中的整数字段。

如果你 绝对知道 您需要存储关于每个轮子的大量变化信息,然后创建一个“轮子”实体。现在,您可以在实体(汽车和车轮)之间建立关系。

如果不是,一个简单的字段就可以了。

在设计数据库时,思考这些关键的决策并尽可能地简化事情对我来说是最重要的。当您构建应用程序的下一层时,它可以使事情变得非常简单和非常困难。

1一致性

随着时间的推移,您的数据库将发生变化,其他人将需要使用它。帮自己和他们一个忙,并确保结构的命名方式使任何具有基本领域知识的合理人员都能够预测表的内容。花点时间写下(可以是一个简单的记事本)您使用的一些基本结构。

实例:

• 主键都以idTableName开头
• 表名的大小写为pascal
• 外键都是TableNameID
• 提取。。。

不管你是否选择使用下划线(用任何其他的下划线转换来代替下划线),只要你在使用或不使用下划线的方式上保持一致,那么在一天结束的时候都不重要。

数据库是数据完整性的最后一道防线。通过存储过程进行所有数据访问,并通过使用检查约束、外键等来强制数据的完整性。正确输入数据,当char(5)更具体和准确时,不要使用varchar(50)。

其他人提到了保持简单的方法。最后但不重要的是不要建造一些东西,因为你“认为”下个月你将需要它。事情变化得很快,你最终会对你想用的东西做更多的维护,而不是你正在使用的东西,如果你填满数据库,这些东西将毫无用处。

与数据库应该建模的真实世界实体的保真度。

我个人建议拿起或借一本“仅用于凡人的数据库设计”。在设计数据库时,你需要考虑的每一件事都会列在那本书中,并且以一种非常有条理和逻辑的顺序来构建数据库。表和列的定义很冗长,但最后使用的每一分钟都是值得的。

我相信如果这本书是通过谷歌图书或亚马逊网站上的页面预览,你可能会读到第一章。

随着时间的推移,你可以从这个网站上学习一些“最佳实践”,但没有什么比在第一次尝试时从头开始以正确的方式设计更好的了。

了解你的数据。

一组基本点:

• 确定系统的用途。
• 确定系统需要的实体。
• 确定每个实体应提供哪些信息。
• 确定实体之间的现有关系
• 用户希望了解和处理您的数据。
• 概念和逻辑数据库设计
• 规范化和ERD
• 用唯一值标识字段。
• 为字段选择适当的数据类型。
• 数据库重构。

您还必须了解数据库的用途。如果是针对事务(OLTP),则应尽可能正常化,目标是尽快完成事务。如果是用于分析和/或报告(OLAP),那么在执行聚合的许多地方,都应该将其非规范化。OLTP数据库的设计考虑不适用于OLAP数据库,反之亦然。

谁来建造和维护它,在哪里,如何,用什么。你有做这件事的方法、程序和过程吗,或者只是简单地尝试一下。 当然,业务需要驱动所需的数据,这些数据应该在独立于实现的ERD中捕获。 但是,您还必须考虑随着时间的推移,谁将维护数据。 以及谁“拥有”这些数据。谁拥有实体和属性定义。

信息需求是最重要的部分。

这是从CMS提供的响应中说“确定系统的目的”的另一种方式。

概念数据建模只是收集和表示信息需求的一种有组织的方式。数据库存储和提供的每个值都连接到一个属性,每个属性连接到一个域。属性依次描述实体或实体之间的关系。主题实体和关系构成了数据所描述的“现实世界”的概念结构。从概念模型构建一个ERD很容易,尽管很繁琐。

之后,您可以选择一个DBMS,设计逻辑数据库,设计物理数据库,然后构建。在每一步中,由于数据独立性,您所做的决策更具可逆性。数据独立性将设计决策封装在数据库中,性能影响除外。当然,你必须了解你的工具。

拥有一个管理模型的工具,并将它们转换为图表和脚本,对于加快这个过程和减少错误非常有帮助。

但是,如果您的信息需求中有严重的错误或遗漏,那么任何巧妙的设计或实现都无法弥补。

一个好的数据库可以判断如下:

如果数据库设计正确,那么您应该能够通过只查看模式来了解业务的运行方式。

换句话说,数据库 是 生意。如果数据库没有反映业务的运行方式,则说明数据库错误或业务错误。

数据库也是你真正需要提前完成的少数事情之一。您总是可以修复错误的代码,但很少能从错误的模式更改中恢复过来。一定要做好。

• 命名约定:坚持一套规则
• 规范化:(规范化的范围)-这取决于读取的数量与数据实体的更新比较的数量。
• 关系完整性和其他限制:有些人主张使用外键,而有些人不主张,但你必须根据自己的要求和个人偏好来选择,因为这是一场大辩论,但我总是选择使用FK
• 创建数据库图表,分析并与团队讨论(如果可能)。