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

问题:

你想在未来使用另一个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.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

问题:

你想在未来使用另一个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.

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

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