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

设计模式通常与面向对象的设计有关。
有用于创建和编程关系数据库的设计模式吗？
当然，许多问题必须具有可重用的解决方案。

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

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

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

• 存储分层数据（例如，具有类型的单个表与具有1：1密钥和差异的多个表...）
• 存储具有可变结构的数据（例如，通用列vs xml vs分隔列...）
• 对数据进行非规范化（如何在影响最小的情况下进行处理等）

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

我也强烈推荐David C. Hay的数据模型和后续的元数据地图，该地图建立在第一个基础上，并且更具雄心和吸引力。仅前言就具有启发性。

Len Silverston的数据模型资源手册丛书第1卷包含通用的数据模型（员工，帐户，运输，购买等），也是查找某些罐头数据库模型的好地方，第2卷包含行业特定的数据模型（会计，医疗保健等），第3卷提供了数据模型模式。

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

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

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

模式不可重用。但是，您可以按照该模式实施向下设计。

关系设计模式包括：

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

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

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

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

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

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

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

8. 单表。[有人称其为反模式；这是一种模式，有时是不好的，有时是好的。]这是一个包含很多预先连接的东西的表，它违反了第二和第三范式。

9. 数组表。该表通过在列中包含数组或值序列来违反第一范式。

10. 混合用途数据库。这是一个规范化的数据库，用于事务处理，但具有许多用于报告和分析的额外索引。这是一种反模式-不要这样做。人们还是这样做，所以它仍然是一种模式。

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

并且这不包括使用和管理的管理和运营模式。

AskTom可能是有关Oracle数据库最佳实践的最有用的单个资源。（我通常只键入“问号”作为针对特定主题的google查询的第一个单词）

我认为用关系数据库来谈论设计模式确实不合适。关系数据库已经是问题的“设计模式”的应用（问题是“如何在保持数据完整性的同时表示，存储和使用数据”，而设计是关系模型）。其他方法（通常认为已过时）是“导航”和“层次”模型（我敢肯定还有很多其他方法）。

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

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

问题：

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

不使用：

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

建议：

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

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

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

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

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

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

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