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

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

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

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

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

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

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

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

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

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

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

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

经过多年的数据库开发，我可以说，在开始之前，有一些不应该做的事情和一些应该回答的问题:

问题:

你想在未来使用另一个DBMS吗?如果是，那么不要使用当前DBMS的特殊SQL东西。删除应用程序中的逻辑。

请勿使用:

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

建议:

Use NVARCHAR or equivalent for Unicode support then you have no problems with codepages. Give every column a unique name. This make it easier on join to select the column. It is very difficult if every table has a column "ID" or "Name" or "Description". Use XyzID and AbcID. Use a resource bundle or equals for complex SQL expressions. It make it easier to switch to another DBMS. Does not cast hard on any data type. Another DBMS can not have this data type. For example Oracle does not have a SMALLINT only a number.

我希望这是一个好的开始。

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

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

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

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