关系数据库设计模式?

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

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

另一个寻找一些预罐装数据库模型的好地方是Len Silverston的数据模型资源书系列卷1包含普遍适用的数据模型(员工、帐户、航运、购买等)，卷2包含特定行业的数据模型(会计、医疗保健等)，卷3提供数据模型模式。

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

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

问题:

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

请勿使用:

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

建议:

• 使用NVARCHAR或等效的Unicode支持，那么代码页就没有问题了。
• 给每个列一个唯一的名称。这使得连接选择列更加容易。如果每个表都有一个列“id”，这是非常困难的。或“;Name"或“;Description"。使用XyzID和AbcID。
• 对于复杂的SQL表达式，使用资源包或等号。它使切换到另一个DBMS更容易。
• 不强制转换任何数据类型。另一个DBMS不能有这种数据类型。例如，Oracle没有SMALLINT，只有一个数字。

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

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

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

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

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

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

1. 使用外键的一对多关系(主-细节，父-子)关系。

2. 一个桥接表的多对多关系。

3. 可选的一对一关系，FK列为null。

4. 星型模式:维度和事实，OLAP设计。

5. 完全归一化的OLTP设计。

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

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

8. < p > Uni-table。[有人称之为反模式;这是一种模式，有时是坏的，有时是好的。这是一个有很多预先连接的东西违反第二和第三正常形式的表。

9. < p >数组表。这是一个违反第一标准形式的表，在列中有一个数组或值序列。

10. < p >综合数据库。这是一个用于事务处理的标准化数据库，但有许多用于报告和分析的额外索引。这是反模式，不要这样做。人们还是会这么做，所以这仍然是一种模式。

大多数设计数据库的人可以轻松地脱口而出半打“It's another one of those”;;这些是他们经常使用的设计模式。

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

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

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

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

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

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

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

话虽如此，您可以将“数据仓库”视为数据库设计中某种程度上独立的“模式”或方法。特别是，你可能对阅读星型模式感兴趣。