【发布时间】：2009-02-24 02:31:41
【问题描述】：
我想从经验丰富的程序员那里了解他们认为在设计新数据库时最重要的考虑因素。
【问题讨论】：
【发布时间】：2009-02-24 02:31:41
【问题描述】：
首先也是最重要的学习和理解业务领域。
1) 您是在关注像繁忙网站那样的高交易率，还是像小公司 HR 系统那样的低使用率
2) 安全性是一个大问题吗？您是在处理个人详细信息还是财务数据。还是只是一个产品目录
3) 你的用户会做很多更新/插入还是主要是只读的
4) 有多少用户，使用模式是什么（峰值负载或均匀分布）
5) 您是否需要 24x7、16x5 或其他正常运行时间，24x7 更难做到，因为您没有停机时间进行维护
6) 数据库的规模有多大？如果它真的很大，你必须设计你的表来考虑那个和/或分区
7) 您是否需要查看具有热故障转移的企业集群，或者只是普通托管
8) 将如何管理数据库，在大多数数据库项目中，95% 的工作都花在为用户及其应用程序开发上，忘记了数据库管理员
9) 数据库管理员，从以前开始包括备份、对其他系统的更改、与其他系统的集成、数据加载
10) 实际上数据加载和使用现有数据本身就是另一个大问题。
这就是开始
【讨论】：
-
安全性、性能、可用性......但数据完整性和准确地建模 UoD 甚至不能让你的 10 件“最重要”的事情:(
-
这一切都与格式良好、干净的实体模型有关。
数据库对于您的业务流程设计来说是次要的，并且应该以直接和简单的方式干净地支持您的业务流程。您将从结构良好、干净的实体模型中获得比你会从这里和那里的索引。因此，一旦定义了您的流程，您就可以将其分解为尽可能干净的“实体”，并具有有意义的关系。一旦你知道你的实体，它们就会转化为数据库表。
要做的最重要的事情之一就是不要过度架构。
为了给你一些答案，我们以“车辆”实体为例。一辆车有多个轮子。您需要做出一个关键决定，即知道车辆上将连接多个轮子。您有 2 个选择 - 您可以将“车轮”设为单独的实体，也可以将“车轮数”设为“车辆”实体中的整数字段。
如果您绝对知道您将需要存储有关每个轮子的大量变化信息，则创建一个“轮子”实体。您现在在实体（汽车和车轮）之间建立了关系。
如果没有，一个简单的字段就可以了。
对我而言，在设计数据库时，考虑这些关键决策并让事情尽可能简单是迄今为止最重要的事情。当您构建应用程序的下一层时，它可以使事情变得非常容易和非常困难。
【讨论】：
-
非常描述性的答案。格式良好、干净的实体模型
1 - 一致性
随着时间的推移，您的数据库会发生变化，其他人将需要使用它。帮自己和他们一个忙，并确保结构的命名方式使得任何具有基本领域知识的理性人都能够预测表的内容。花点时间写下（可以是简单的记事本）你使用的一些基本结构。
例子：
- 主键都以 IdTableName 开头
- 表名的大小写是 Pascal
- 外键都是TableNameId
- 分机...
您是否选择使用下划线（将下划线替换为任何其他转换）在一天结束时并不重要，只要您在使用或不使用它们的方式上保持一致即可。
您的数据库是数据完整性的最后一道防线。通过存储过程进行所有数据访问，并通过使用检查约束、外键等强制数据的完整性。正确键入数据，当 CHAR(5) 更具体和准确时，不要使用 VARCHAR(50)。
其他人提到了一些关于保持简单的事情。最后但并非最不重要的一点是，不要因为你“认为”下个月需要它而构建一些东西。事情变化很快，你最终会对你“认为”你将要使用的东西做更多的维护，而不是你正在使用的东西，如果你填满你的数据库，这些东西将毫无用处。
【讨论】：
忠实于数据库应该建模的真实世界实体。
【讨论】：
-
+1 如果你没有那个，你会遇到一个永远无法正常工作的烂摊子。
我个人建议拿起或借用一本“为凡人设计的数据库”。您在设计数据库时需要考虑的所有内容都将在该书中列出，并且您可以按照非常有条理和合乎逻辑的顺序构建数据库。 Table 和 Column 的定义很乏味，但最终值得每一分钟使用。
如果通过 Google 图书或通过 Amazon.com 上的页面预览，我相信您可能能够阅读本书的第一章。
随着时间的推移，您可以从中学习一些花絮，或者从这个网站作为“最佳实践”学习，但没有什么比在第一次尝试时就以正确的方式从头开始设计更好的了。
【讨论】：
一组基本点：
- 确定系统的用途。
- 确定您的系统需要的实体。
- 确定每个实体应提供哪些信息。
- 确定实体之间的现有关系
- 用户希望了解您的数据以及如何处理您的数据。
- 概念和逻辑数据库设计
- 归一化和 ERD
- 识别具有唯一值的字段。
- 为您的字段选择适当的数据类型。
- 数据库重构。
【讨论】：
了解您的数据。
【讨论】：
您还必须了解数据库的用途。如果是针对事务（OLTP），应该尽量规范化，目标是让事务尽快完成。如果它用于分析和/或报告 (OLAP)，则应在您将执行聚合的许多地方对其进行非规范化。 OLTP 数据库的设计注意事项不适用于 OLAP 数据库，反之亦然。
【讨论】：
谁来构建和维护它，在哪里，如何以及用什么。你有方法、程序和流程来做这件事还是只是临时做。 当然，业务需求驱动所需的数据，这些数据应在独立于实施的 ERD 中捕获。 但是，您还必须考虑随着时间的推移谁将维护数据。 以及谁“拥有”数据。谁拥有实体和属性定义。
【讨论】：
信息需求是最重要的部分。
这是 CMS 提供的回复中“确定系统用途”的另一种说法。
概念数据建模只是收集和呈现信息需求的一种有组织的方式。数据库存储和提供的每个值都连接到一个属性，每个属性都连接到一个域。反过来，属性描述实体或实体之间的关系。主题实体和关系构成了数据描述的“现实世界”的概念结构。从概念模型构建 ERD 很容易，尽管很乏味。
之后，您可以选择一个 DBMS，设计逻辑数据库，设计物理数据库，然后构建。由于数据独立性，在每一步中，您做出的决定都更加可逆。数据独立性将设计决策封装在数据库内部，性能后果除外。当然，您必须了解您的工具。
拥有用于管理模型并将其转换为图表和脚本的工具对于加快此过程并减少错误非常有帮助。
但是，如果您的信息需求存在严重错误或遗漏，再多的巧妙设计或实施也无法弥补。
【讨论】：
一个好的数据库可以这样判断：
如果数据库设计得当，您应该能够通过查看架构来了解企业的运作方式。
换句话说，数据库就是的业务。如果数据库不能反映业务是如何运行的，要么是数据库有问题，要么是业务有问题。
数据库也是您真正需要预先确定的少数几件事之一。您总是可以修复错误的代码，但很少能从错误的架构更改中退出。确保做对了。
【讨论】：
- 命名约定：遵守一套规则
- 规范化：（规范化程度）- 这将取决于数据实体的读取次数与更新次数的比较。
- 关系完整性和其他约束：有些人提倡使用外键，而有些人不提倡，但您必须根据自己的要求和个人偏好进行选择，因为这是一场大辩论，但我总是会选择使用外键
- 尽可能创建数据库图表，与团队进行分析和讨论。
【讨论】：