Design patterns 关系数据库设计模式？

设计模式通常与面向对象设计相关。
有用于创建和编程的软件吗？
许多问题肯定有可重用的解决方案

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

是否有类似于的此类模式的在线存储库

---

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

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

---

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

我还强烈推荐David C.Hay's和后续版本，它们建立在第一个版本的基础上，更具雄心和吸引力。仅序言就很有启发性

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

---

最后，虽然这本书表面上是关于UML和对象建模的，但彼得·科德的书提供了一个“原型”实体建模的驱动过程从任何对象/数据模型都有4个核心原型这一前提出发经过多年的数据库开发，我可以说在开始之前，您应该回答一些问题：

问题：

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

不使用：

• 表名和列名中的空格
• 表名和列名中的非Ascii字符
• 绑定到特定的小写或大写。不要使用只有小写和大写字母不同的两个表或列
• 不对表或列名称使用SQL关键字，如“FROM”、“BETWEEN”、“DELETE”等

推荐：

• 使用NVARCHAR或等效软件支持unicode，那么代码页就没有问题了
• 为每一列指定一个唯一的名称。这使得在连接时选择柱更容易。如果每个表都有一列“ID”或“Name”或“Description”，这是非常困难的。使用XyzID和AbcID
• 对于复杂的SQL表达式，请使用资源束或等同物。它使切换到另一个DBMS更加容易
• 不强制转换任何数据类型。另一个DBMS不能具有此数据类型。例如，Oracle DAE没有SMALLINT，只有一个数字

---

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

你的问题有点含糊不清，但我认为可以将其视为一种设计模式。对于未实现

合并

的语言，（如果存在合适的行，

更新

；否则

插入

）存在。

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

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

模式的可重用性并不低。但是，您可以按照该模式实现向下设计

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

使用外键的一对多关系（主详细信息、父子关系）

与桥接表的多对多关系

在FK列中使用空值管理可选的一对一关系

星型模式：维度和事实，OLAP设计

完全规范化的OLTP设计

维度中有多个索引搜索列

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

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

数组表。这是一个表，它通过在列中包含数组或值序列而违反了第一个标准形式

混合使用数据库。这是一个用于事务处理的标准化数据库，但有许多用于报告和分析的额外索引。这是一种反模式——不要这样做。不管怎么说，人们都这样做，所以这仍然是一种模式

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

---

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

取决于您所指的模式。如果您考虑的是个人/公司/事务/产品等，那么是的-已经有很多通用数据库模式可用

如果你在想工厂，辛格尔顿。。。然后不-你不需要任何这些，因为它们对于DB编程来说太低了

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

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

可能是关于Oracle DBs最佳实践的唯一最有用的资源。（我通常只在谷歌查询某个特定主题时键入“asktom”作为第一个词）

我认为用关系数据库来谈论设计模式是不合适的。关系数据库已经是“设计模式”的应用