关系数据库设计模式？ [关闭]

Posted 2023-02-16

【中文标题】关系数据库设计模式？ [关闭]

【英文标题】：Relational Database Design Patterns? [closed]

【发布时间】：2010-09-13 19:50:22

【问题描述】：

设计模式通常与面向对象的设计有关。是否有 design patterns 用于创建和编程 relational databases？ 许多问题肯定有可重用的解决方案。

示例包括表格设计、存储过程、触发器等模式......

是否有此类模式的在线存储库，类似于 martinfowler.com？

---

模式可以解决的问题示例：

存储分层数据（例如，具有类型的单个表与具有 1:1 键和差异的多个表...） 存储具有可变结构的数据（例如，通用列 vs xml vs 分隔列...） 非规范化数据（如何在影响最小的情况下做到这一点等...）

【问题讨论】：

我会在这里声称最好的 Q&A 分层数据存储：***.com/questions/4048151/…

根据我们的on-topic 指导，“有些问题仍然是题外话，即使它们属于上面列出的类别之一：...向我们提问的问题推荐或查找书籍、工具、软件库、教程或其他场外资源是题外话..."

@RobertColumbia 这个问题是 on-topic 在 2008 年被问到时......

查看这个关于关系数据库和许多软件工程领域的设计模式资源列表github.com/DovAmir/awesome-design-patterns

【参考方案1】：

Martin Fowler 的签名系列中有一本书叫Refactoring Databases。这提供了重构数据库的技术列表。我不能说我听过这么多数据库模式列表。

我还强烈推荐 David C. Hay 的 Data Model Patterns 和后续的 A Metadata Map，它建立在第一个之上，并且更加雄心勃勃和有趣。序言本身就很有启发性。

Len Silverston 的数据模型资源书系列也是寻找一些预装数据库模型的好地方Volume 1 包含普遍适用的数据模型（员工、帐户、运输、采购等），Volume 2 包含行业特定数据模型（会计、医疗保健等），Volume 3 提供数据模型模式。

最后，虽然这本书表面上是关于 UML 和对象建模的，但 Peter Coad 的 Modeling in Color With UML 提供了一个“原型”驱动的实体建模过程，前提是任何对象/数据模型都有 4 个核心原型

【讨论】：

这本书的标题是 [Refactoring Databases: Evolutionary Database Design][1]，作者是 Scott W. Ambler 和 Pramod J. Sadalage，确实非常好。 [1]：ambysoft.com/books/refactoringDatabases.html

关于 Ambler 书：不，您不能将“插入列”或“创建 FK 约束”列为模式，原因相同 The Gang of 4 book 没有列出“for”循环是一种模式。

这不是一种模式，而是一种重构。像提取方法，或重命名参数。重构和模式齐头并进。

添加一个：Fowler 的“分析模式”。类似于 Hay 的东西

Len Silverston 的第 3 卷是我认为的唯一一本“设计模式”。前 2 个显示了在编写书籍的时间范围内常见的示例数据模型。尽管第 3 卷实际上针对给定的问题场景有多种设计模式。例如，第 4 章涵盖了层次结构/聚合/点对点场景，然后提供了多种设计来解决每种设计的优缺点。

【参考方案2】：

设计模式不是简单的可重用解决方案。

根据定义，设计模式是可重用的。它们是您在其他好的解决方案中发现的模式。

一个模式不是简单可重用的。但是，您可以按照该模式实现您的羽绒设计。

关系设计模式包括：

使用外键的一对多关系（主从关系、父子关系）。

与桥接表的多对多关系。

在 FK 列中使用 NULL 管理可选的一对一关系。

Star-Schema：维度和事实，OLAP 设计。

完全规范化的 OLTP 设计。

一个维度中有多个索引搜索列。

“查找表”包含一个或多个应用程序使用的 PK、描述和代码值。为什么有代码？我不知道，但是当必须使用它们时，这是一种管理代码的方法。

单表。 [有人称之为反模式；这是一种模式，有时很糟糕，有时很好。] 这是一张包含许多违反第二和第三范式的预连接内容的表。

数组表。这是一个违反第一范式的表，列中有一个数组或值序列。

混合用途数据库。这是一个为事务处理而规范化的数据库，但有许多额外的索引用于报告和分析。这是一种反模式——不要这样做。无论如何人们都会这样做，所以它仍然是一种模式。

大多数设计数据库的人都可以轻松地说出六个“这是另一个”；这些是他们经常使用的设计模式。

这不包括使用和管理的行政和运营模式。

【讨论】：

我见过的其他一些模式是多父子表（即，像可以链接到任何其他表的具有 objecttype 和 objectid 的全局注释）或自引用 FK（即，雇员.经理->雇员.id）。我还使用了一个包含许多列的单例配置表。

为什么混合使用的数据库是一种反模式。如果我想从数据库中提取报告，我应该怎么做？

@lhnz：您不能从事务数据库设计中提取 lot 的 large 报告——锁定报告会减慢事务处理速度。复杂的连接（一遍又一遍地执行）是对事务性能的另一个打击。您不能在一个数据库中同时执行这两项操作。要制作大量大型报表，您必须将数据移动到星型模式中。星型模式模式针对报告进行了优化。并且移动数据会消除任何锁定争用。

如果您让表保存更多“内聚”数据，规范化架构会减少行锁争用吗？我的想法是，如果一个大表正在为 2 种数据集的写入提供服务，但它们都在同一行中，这将导致不必要的锁争用。

【参考方案3】：

AskTom 可能是有关 Oracle 数据库最佳实践的最有用的资源。 （我通常只输入“asktom”作为特定主题的谷歌查询的第一个词）

我认为用关系数据库谈论设计模式并不合适。关系数据库已经是“设计模式”对问题的应用（问题是“如何在保持数据完整性的同时表示、存储和处理数据”，而设计就是关系模型）。其他方法（通常被认为已过时）是导航和分层模型（我相信还有许多其他方法存在）。

话虽如此，您可能会将“数据仓库”视为数据库设计中某种独立的“模式”或方法。特别是，您可能有兴趣阅读Star schema。

【参考方案4】：

经过多年的数据库开发，我可以说在开始之前您应该回答一些不可行的问题和一些问题：

问题：

您想在将来使用另一个 DBMS 吗？如果是，则不要使用当前 DBMS 的特殊 SQL 内容。删除应用程序中的逻辑。

请勿使用：

表名和列名中的空格 表名和列名中的非 ASCII 字符 绑定到特定的小写或大写。并且永远不要使用仅区分大小写的 2 个表或列。 不要对“FROM”、“BETWEEN”、“DELETE”等表或列名称使用 SQL 关键字

建议：

使用 NVARCHAR 或等效的 Unicode 支持，那么代码页不会有任何问题。 为每一列指定一个唯一的名称。这使得加入时更容易选择列。如果每个表都有一列“ID”或“名称”或“描述”，这将非常困难。使用 XyzID 和 AbcID。 对复杂的 SQL 表达式使用资源包或等号。它使切换到另一个 DBMS 变得更加容易。 不对任何数据类型进行强制转换。另一个 DBMS 不能有这种数据类型。例如，Oracle 没有 SMALLINT 只有一个数字。

我希望这是一个好的起点。

【讨论】：

尽管您的 cmets 很有启发性和实用性，但它们不是设计模式。它们是最佳实践。谢谢，

我不同意关于唯一列名的建议。我宁愿说 customer.id 来消除歧义，也不愿说 customerid 即使在没有什么可以消除歧义的地方。

【参考方案5】：

你的问题有点含糊，但我想UPSERT 可以被认为是一种设计模式。对于未实现MERGE 的语言，存在a number of alternatives to solve the problem（如果存在合适的行，则存在UPDATE；否则存在INSERT）。

【讨论】：

UPSERT 是一个命令，也是 SQL 语言的一部分。这不是一种模式。

UPSERT 是 SQL 语言的某些变体中的命令 - 许多平台没有它，或者只是最近才获得它。

@ToddR - 我听说（有点愤世嫉俗地）“模式”实际上只不过是语言或模型中的缺点，用户必须为其创建变通方法。我不知道 UPSERT 是做什么的，但是虽然它已添加到 一些 SQL 而不是其他 SQL，但它是一种模式。

【参考方案6】：

取决于你所说的模式是什么意思。如果您正在考虑 Person/Company/Transaction/Product 等，那么是的 - 已经有很多通用数据库模式可用。

如果您正在考虑 Factory、Singleton... 那么不 - 您不需要任何这些，因为它们对于 DB 编程来说太低级了。

如果您正在考虑数据库对象命名，那么它属于约定范畴，而不是设计本身。

顺便说一句，S.Lott，一对多和多对多关系不是“模式”。它们是关系模型的基本构建块。

【讨论】：

像（人，客户，员工）这样的数据库继承怎么样，也许这种事情可以被认为是设计模式？