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

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

有没有类似于martinfowler.com的这种模式的在线存储库？

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

• 存储分层数据(例如，具有类型的单个表与具有1:1键和差异的多个表…)
• 存储具有可变结构的数据(例如，通用列、XML列和分隔列…)
• 将数据非规范化(如何在影响最小的情况下执行此操作等…)

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

我还强烈推荐DavidC.Hay的数据模型模式和后续的元数据映射，它建立在第一个模型之上，并且更具野心和吸引力。序言本身就很有启发性。

Len Silverston的数据模型资源手册系列也是寻找一些预屏蔽数据库模型的好地方。第1卷包含普遍适用的数据模型(员工、账户、运输、采购等)，第2卷包含行业特定的数据模型(会计、保健等)，第UME3提供了数据模型模式。

最后，虽然这本书表面上是关于UML和对象建模的，但是PeterCoad的UML颜色建模提供了一个"原型"驱动的实体建模过程，从任何对象/数据模型都有4个核心原型开始。

这里有一个链接指向一位开发了几百个免费数据库模式的先生。

http://www.databaseanswers.org/datau模型/

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

其次，SQL Server杂志偶尔会有一个叫做"数据建模器"的专栏，它非常有教育意义，并且通常包含给定系统的完整模式。

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

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

一个模式不可重复使用。但是，您可以按照模式实现向下的设计。

关系设计模式包括：

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

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

看看这个博客——数据库程序员。

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

JoeCelko的书非常适合这种类型的东西，特别是"智能SQL"。他对常见问题有一些创新的解决方案，其中大部分是可重用的设计模式。

网址：http://www.celko.com/books.htm

asktom可能是Oracle DBS上关于最佳实践的唯一最有用的资源。(我通常只输入"asktom"作为谷歌查询特定主题的第一个词)

我认为谈论关系数据库的设计模式并不真正合适。关系数据库已经是"设计模式"对问题的应用(问题是"如何在保持数据完整性的同时表示、存储和使用数据"，而设计是关系模型)。其他方法(通常被认为是过时的)是导航和层次模型(我注意到还有很多其他方法存在)。

尽管如此，您可能会认为"数据仓库"在数据库设计中是一种有点独立的"模式"或方法。尤其是，您可能对阅读星型模式感兴趣。

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

问题：

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

不使用：

• 表名和列名中的空格
• 表名和列名中的非ASCII字符
• 绑定到特定的小写或大写。不要使用只与小写和大写不同的两个表或列。
• 不将SQL关键字用于表或列名称，如"From"、"Between"、"Delete"等

建议：

• 使用nvarchar或等效物支持Unicode，那么代码页就没有问题了。
• 为每一列指定一个唯一的名称。这使得在连接时更容易选择列。如果每个表都有一个列"id"或"name"或"description"，这是非常困难的。使用xyzid和abcid。
• 对复杂的SQL表达式使用资源束或等于。它使切换到另一个DBMS更容易。
• 不会对任何数据类型强制转换。另一个DBMS不能具有此数据类型。例如，Oracle DAE没有smallint，只有一个数字。

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

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

如果你认为是工厂，辛格尔顿…那么不-你不需要这些，因为它们对于数据库编程来说太低了。

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

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

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

这本书看起来很有趣