寻找示例数据库设计的好地方 - 最佳实践[关闭]

Posted 2023-03-10

【中文标题】寻找示例数据库设计的好地方 - 最佳实践[关闭]

【英文标题】：Good place to look for example Database Designs - Best practices [closed]

【发布时间】：2011-01-25 08:57:00

【问题描述】：

我的任务是设计一个数据库来存储我们公司的大量信息。因为任务相当大并且包含多个用户应该能够做的事情的模块，所以我担心为此设计一个好的数据模型。我只是不想最终得到一个设计糟糕的数据库。

我想为合同/计费/订单等提供一些体面的数据库结构示例，以便将它们组合到一个不错的关系数据库中。是否有任何资源可以帮助我提供一些关于此的示例？

【问题讨论】：

这么“大”的问题，居然这么短的时间你就接受了答案？

【参考方案1】：

Barry Williams 为各种应用程序发布了一个包含大约 600 个数据模型的库。几乎可以肯定，它会为您的所有子系统提供“十人入门”。访问这个图书馆是免费的，所以check it out。

听起来这是您的组织想要的大型“企业级”应用程序，而您似乎是数据库的初学者。如果可能的话，你应该从一个子系统开始——比如说，订单——然后让它工作。不仅是数据库表，还有一些骨架前端。一旦这足够好，添加另一个相关的子系统，例如计费。你不想以一个庞大的怪物告终。

还要确保您拥有合适的数据建模工具。 SQL Power Architect 作为免费工具已经足够好了。

【讨论】：

您好，我尝试下载免费工具。 googlecode.com 给出了一个关于文件太大并因此被阻止的错误。你能和我们分享你下载的东西吗？谢谢你，Anjan Bacchu

+1 表示 Barry William 的数据模型databaseanswers.org/data_models

【参考方案2】：

在您开始阅读规范化之前，直到您对此完全没有疑问。如果你只是在学校做这个，你可能还没有足够的了解它来设计。

仔细收集您对每个模块的要求。你需要知道：

业务规则（特定于应用程序并且必须在数据库中强制执行，因为无论来源如何，它们都必须对所有记录强制执行），

是否存在法律或监管问题（例如 HIPAA 或 Sarbanes-Oxley 要求） 安全性（数据是否需要加密？）

您需要存储哪些数据以及为什么（这些数据在其他任何地方都可用）

哪些数据只有一行数据，哪些需要多行数据？

您打算如何强制每个表中行的唯一性？您有自然键还是需要代理键（几乎在所有情况下都建议使用代理键）？

您需要复制吗？

您需要审核吗？

如何将数据输入数据库？它是一次来自应用程序一条记录（甚至来自多个应用程序），还是来自 ETL 工具或另一个数据库的批量插入。

您是否需要知道谁输入了记录以及何时输入（这在企业系统中很可能是必需的。

您需要什么样的查找表？当您可以使用查找表并将用户限制为值时，数据输入会更加准确。

您需要什么样的数据验证？

系统大约有多少条记录？您需要有一个想法才能知道创建测试数据有多大。

您将如何查询数据？您将使用存储过程或 ORM 或动态查询吗？

在您的设计中要记住一些非常基本的事情。为您的数据选择正确的数据类型。不要在字符串字段中存储您打算对其进行数学运算的日期或数字。将不是数学候选的数字（部件号、邮政编码、电话号码等）存储为字符串数据，因为您可能需要前导零。不要在一个字段中存储多条信息。所以没有逗号连接的列表（这些表示需要一个相关的表），当你发现自己在做类似 phone1、phone2、phone 3 的事情时，请立即停下来设计一个相关的表。出于数据完整性目的使用外键。

在您的设计中始终考虑数据完整性。没有完整性的数据是没有意义和无用的。为性能而设计，这在数据库设计中至关重要，而不是过早的优化。数据库不容易重构，因此重要的是在第一时间就将性能方程式中最关键的部分弄对。事实上，所有数据库都需要针对数据完整性、性能和安全性进行设计。

不要害怕有多个连接，正确索引这些会执行得很好。不要试图将所有内容都放入实体值类型表中。尽量少用这些。尝试学习从处理数据集的角度进行思考，这将有助于您的设计。数据库经过优化，可以成套地做事。

还有更多，但这足以开始消化。

【参考方案3】：

尽量在此处将您的顾虑分开。用户能够更新数据库更多的是一个“应用程序设计”问题。如果您的数据库设计正确，那么应该为它开发一个不错的前端。

首先要看的是Normalization。这是从您的表中消除任何冗余数据的过程。这将有助于保持您的数据库整洁，并且只存储与您的需求相关的信息。

【讨论】：

感谢您的回答，我为此上过学，知道什么是标准化。我在这里非常小心，因为我不希望我的第一个真正的项目失败:)。这就是为什么我想看一些规范化关系数据库的例子。

@Younes - 不要太担心项目失败，每个人都会遇到这种情况......即使是最优秀的开发人员 :) 只要你彻底地整理了必须 i> 存储在数据库中，那么设计数据库应该不会太难。

感谢您的评论，我尽量不要太担心。

【参考方案4】：

数据模型资源书。

http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=dp_cp_ob_b_title_0

很重的东西，但做得很好。一共3卷……

有很多非常好的通用结构——但它们并不容易，因为它们涵盖了所有内容；）不过总是一个很好的起点。

【参考方案5】：

数据库不应该是模型。它用于在工作会话之间保存信息。

您不应在数据模型上构建应用程序，而应在遵循业务逻辑的良好面向对象模型上构建应用程序。

一旦您的对象模型完成，然后考虑如何保存和加载它，以及随之而来的所有数据库设计。

（但显然你的公司只是想让你设计一个数据库？而不是一个应用程序？）

【讨论】：

正确，但我已经知道了。这并不是说我不知道​​数据库的用途或任何东西；）。只想要一个像样的数据库。

多个应用程序可能共享一个数据库。此外，公司数据的完整性对其生存至关重要。因此，数据库对公司数据进行准确建模非常重要。

我能想到的最糟糕的设计企业型数据库的方法。