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

如果你在想工厂，单例……那么不——你不需要这些，因为它们对于DB编程来说太低了。

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

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

你的问题有点模糊，但我认为UPSERT可以被认为是一种设计模式。对于没有实现MERGE的语言，有许多替代方案可以解决这个问题(如果存在合适的行，则UPDATE;else INSERT)存在。

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

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

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

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

One-to-Many relationships (master-detail, parent-child) relationships using a foreign key. Many-to-Many relationships with a bridge table. Optional one-to-one relationships managed with NULLs in the FK column. Star-Schema: Dimension and Fact, OLAP design. Fully normalized OLTP design. Multiple indexed search columns in a dimension. "Lookup table" that contains PK, description and code value(s) used by one or more applications. Why have code? I don't know, but when they have to be used, this is a way to manage the codes. Uni-table. [Some call this an anti-pattern; it's a pattern, sometimes it's bad, sometimes it's good.] This is a table with lots of pre-joined stuff that violates second and third normal form. Array table. This is a table that violates first normal form by having an array or sequence of values in the columns. Mixed-use database. This is a database normalized for transaction processing but with lots of extra indexes for reporting and analysis. It's an anti-pattern -- don't do this. People do it anyway, so it's still a pattern.

大多数设计数据库的人可以轻松地脱口而出半打“这是另一个”;这些是他们经常使用的设计模式。

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

AskTom可能是关于Oracle db最佳实践的最有用的资源。(我通常只是键入“asktom”作为谷歌查询特定主题的第一个词)

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

话虽如此，您可以将“数据仓库”视为数据库设计中某种程度上独立的“模式”或方法。您可能特别有兴趣阅读关于Star模式的内容。

Martin Fowler的签名系列中有一本书叫做重构数据库。其中提供了重构数据库的一系列技术。我从来没有听过这么多的数据库模式。

我还强烈推荐David C. Hay的《数据模型模式》和后续的《元数据地图》，它建立在第一本的基础上，更加雄心勃勃和有趣。前言本身就很有启发性。

Len Silverston的数据模型资源书系列第1卷包含普遍适用的数据模型(员工、帐户、运输、购买等)，第2卷包含特定于行业的数据模型(会计、医疗保健等)，第3卷提供数据模型模式。

最后，虽然这本书表面上讲的是UML和对象建模，但Peter Coad的《用UML进行彩色建模》从任何对象/数据模型都有4个核心原型的前提出发，提供了一个实体建模的“原型”驱动过程

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

如果你在想工厂，单例……那么不——你不需要这些，因为它们对于DB编程来说太低了。

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

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