关系数据库设计模式？

Question

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

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

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

---

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

• 存储分层数据（例如，带有类型的单表与具有1：1键和差异的多个表...）
• 存储具有可变结构的数据（例如，通用列vs xml vs分隔列...）
• 对数据进行非规范化（如何以最小的影响进行操作等）

Answer 1

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

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

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

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

Answer 2

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

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

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

其次，SQL Server Magazine偶尔会出现一个名为“The Data Modeler”的专栏，它非常具有教育意义，通常包含给定系统的完整模式。

Answer 3

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

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

模式不可重复使用。但是，您可以按照模式实现您的羽绒设计。

关系设计模式包括：

1. 使用外键的一对多关系（主 - 详细信息，父子关系）。

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

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

4. Star-Schema：Dimension and Fact，OLAP design。

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

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

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

8. 的Uni-表。 [有人称之为反模式;这是一种模式，有时它很糟糕，有时它很好。]这是一张包含许多违反第二和第三范式的预先加入的表格。

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

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

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

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

Answer 4

查看此博客 - The Database Programmer。

他描述了一些database patterns。

Answer 5

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

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

Answer 6

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

我认为用关系数据库谈论设计模式并不合适。关系数据库已经是对问题的“设计模式”的应用（问题是“如何在保持其完整性的同时表示，存储和处理数据”，并且设计是关系模型）。其他approches（通常被认为是过时的）是Navigational和Hierarchical模型（我不知道其他许多其他模型）。

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

Answer 7

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

<强>的问题：

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

不使用：

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

<强> recomendations：

• 使用NVARCHAR或等效的unicode支持，然后您可以使用代码页。
• 为每列添加唯一名称。这使得连接更容易选择列。如果每个表都有一列“ID”或“名称”或“描述”，则非常困难。使用XyzID和AbcID。
• 对复杂的SQL表达式使用资源包或等号。它可以更容易切换到另一个DBMS。
• 不对任何数据类型施加压力。另一个DBMS不能具有此数据类型。例如，Oracle daes没有SMALLINT只有一个数字。

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

Answer 8

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

Answer 9

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

如果您正在考虑Factory，Singleton ......那么不 - 您不需要任何这些，因为它们的DB编程水平太低。

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

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

Answer 10

This book looks interesting

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5