关系数据库设计模式？

StackOverflow https://stackoverflow.com/questions/145689

题

设计模式通常与面向对象设计相关。
在那儿 设计模式 用于创建和编程 关系数据库?
许多问题肯定必须有可重用的解决方案。

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

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

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

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

解决方案

马丁·福勒的签名系列有一本书叫做 重构数据库. 。这提供了重构数据库的技术列表。我不能说我听过这么多数据库模式列表。

我还强烈推荐 David C.海伊的 数据模型模式 以及后续行动 元数据图 它建立在第一个基础上，并且更加雄心勃勃和有趣。光是序言就很有启发性。

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

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

其他提示

这是一位开发了数百种免费数据库模式的绅士的链接。

http://www.databaseanswers.org/data_models/

也许如果您必须快速构建数据库，这将为您提供给定模式中的表和关系的起点。请记住，您可能需要修改此起点。我发现它非常有用。

其次，SQL Server 杂志偶尔有一个名为“数据建模者”的专栏，该专栏非常具有教育意义，并且通常包含给定系统的完整架构。

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

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

模式并不是可以轻易重用的。不过，您可以按照该模式实现您的羽绒设计。

关系设计模式包括：

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

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

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

  4. 星型架构：维度和事实，OLAP 设计。

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

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

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

  8. 单表。[有些人称之为反模式；有些人称之为反模式；这是一种模式，有时是坏的，有时是好的。] 这是一个包含大量预连接内容的表，违反了第二范式和第三范式。

  9. 数组表。该表违反了第一范式，列中包含数组或值序列。

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

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

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

看看这个博客 - 数据库程序员.

他描述了一些 数据库模式.

Joe Celko 的书非常适合此类内容，特别是“Smarties 的 SQL”。他对常见问题有一些创新的解决方案，其中大部分是可重用的设计模式。

http://www.celko.com/books.htm

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

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

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

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

问题：

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

不使用：

  • 表名和列名中的空格
  • 表名和列名中的非 Ascii 字符
  • 绑定到特定的小写或大写。切勿使用仅小写和大写不同的 2 个表或列。
  • 不使用 SQL 关键字作为表或列名称，例如“FROM”、“BETWEEN”、“DELETE”等

推荐：

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

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

你的问题有点模糊，但我想 UPSERT 可以被认为是一种设计模式。对于没有实现的语言 MERGE, 解决问题的多种选择 （如果存在合适的行， UPDATE;别的 INSERT） 存在。

取决于你所说的模式是什么意思。如果您正在考虑个人/公司/交易/产品等，那么是的 - 已经有很多通用数据库模式可用。

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

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

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

这本书看起来很有趣

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top