290

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

示例将包括用于表设计、存储过程、触发器等的模式......

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

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

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

6 回答 6

163

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

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

Len Silverston 的 Data Model Resource Book Series第 1 卷包含普遍适用的数据模型（员工、帐户、运输、采购等），第 2 卷包含行业特定的数据模型（会计、医疗保健等），第 3 卷提供了数据模型模式。

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

于 2008-09-28T11:44:48.520 回答
48

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

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

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

关系设计模式包括以下内容：

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

  2. 与桥接表的多对多关系。

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

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

  5. 完全标准化的 OLTP 设计。

  6. 一个维度中的多个索引搜索列。

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

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

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

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

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

这不包括使用和管理的管理和操作模式。

于 2008-09-28T13:36:52.167 回答
6

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

I don't think it's really appropriate to speak of design patterns with relational databases. Relational databases are already the application of a "design pattern" to a problem (the problem being "how to represent, store and work with data while maintaining its integrity", and the design being the relational model). Other approches (generally considered obsolete) are the Navigational and Hierarchical models (and I'm nure many others exist).

Having said that, you might consider "Data Warehousing" as a somewhat separate "pattern" or approach in database design. In particular, you might be interested in reading about the Star schema.

于 2008-10-10T09:19:17.710 回答
4

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

问题：

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

不使用：

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

建议：

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

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

于 2008-09-28T11:55:34.470 回答
1

你的问题有点含糊，但我想UPSERT可以被认为是一种设计模式。对于不实现 的语言MERGE，存在许多解决问题的替代方案（如果存在合适的行，则UPDATE; else INSERT）存在。

于 2008-09-28T12:18:05.930 回答
1

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

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

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

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

于 2008-09-30T04:12:35.097 回答