关系数据库设计模式？
设计模式通常与面向对象的设计有关。
有用于创建和编程关系数据库的设计模式吗？
当然，许多问题必须具有可重用的解决方案。
示例包括表设计，存储过程，触发器等的模式。
是否存在类似于martinfowler.com的此类模式的在线存储库？
模式可以解决的问题示例：
- 存储分层数据(例如具有类型的单个表与具有1：1密钥和差异的多个表...)
- 存储具有可变结构的数据(例如，通用列vs xml vs分隔列...)
- 对数据进行非规范化(如何在影响最小的情况下进行处理等)
解决方案
乔·塞尔科(Joe Celko)的书籍非常适合这类事情，尤其是" SQL for Smarties"。他为常见问题提供了一些创新的解决方案，其中大多数是可重用的设计模式。
http://www.celko.com/books.htm
Martin Fowler的签名系列中有一本书叫做"重构数据库"。这提供了用于重构数据库的技术列表。我不能说我听过这么多数据库模式列表。
我也强烈推荐David C. Hay的数据模型和后续的元数据地图，该地图建立在第一个基础上，并且更具雄心和吸引力。仅前言是有启发性的。
Len Silverston的数据模型资源手册丛书第1卷还包含一些通用的数据模型(员工，帐户，运输，购买等)，也是寻找某些预定义数据库模型的好地方，第2卷包含了特定于行业的数据模型(会计，医疗保健等)，第3卷提供了数据模型模式。
最后，尽管这本书表面上是关于UML和对象建模的，但Peter Coad的"使用UML进行颜色建模"提供了"原型"驱动的实体建模过程，前提是任何对象/数据模型都有4种核心原型
经过多年的数据库开发，我可以说有一些不可行和一些问题，我们应该在开始之前回答这些问题：
问题：
- 我们将来是否要使用另一个DBMS？如果是，则不使用当前DBMS的特殊SQL内容。在应用程序中删除逻辑。
不使用：
- 表名和列名中的空格
- 表和列名称中的非Ascii字符
- 绑定到特定的小写或者大写字母。并且永远不要使用仅与小写和大写字母不同的2个表或者列。
- 对于表或者列名称(例如" FROM"，" BETWEEN"，" DELETE"等)，不使用SQL关键字
建议：
- 使用NVARCHAR或者同等版本的unicode支持，那么代码页就没有问题。
- 为每列指定一个唯一的名称。这使得在连接时更容易选择列。如果每个表的" ID"或者" Name"或者" Description"列都非常困难。使用XyzID和AbcID。
- 对于复杂的SQL表达式，请使用资源束或者等于资源束。这使得切换到另一个DBMS变得更加容易。
- 不对任何数据类型强制转换。另一个DBMS不能具有此数据类型。例如，Oracle敢于没有SMALLINT只有一个数字。
我希望这是一个良好的起点。
问题有点含糊，但我想可以将" UPSERT"视为一种设计模式。对于未实现" MERGE"的语言，存在许多解决问题的替代方法(如果存在合适的行，则为" UPDATE"；否则为" INSERT")。
设计模式并非简单可重用的解决方案。
根据定义，设计模式是可重用的。它们是我们在其他好的解决方案中检测到的模式。
模式不可重用。但是，我们可以按照该模式实施向下设计。
关系设计模式包括：
- 使用外键的一对多关系(主从，父子关系)。
- 与桥表的多对多关系。
- 在FK列中使用NULL管理的可选一对一关系。
- 星型：维度和事实，OLAP设计。
- 完全标准化的OLTP设计。
- 一个维度中的多个索引搜索列。
- "查找表"，包含一个或者多个应用程序使用的PK，描述和代码值。为什么要有代码？我不知道，但是当必须使用它们时，这是一种管理代码的方式。
- 单表。 [有人称其为反模式；这是一种模式，有时是不好的，有时是好的。]这是一个包含很多预先连接的东西的表，它违反了第二和第三范式。
- 数组表。该表通过在列中包含数组或者值序列来违反第一范式。
- 混合用途数据库。这是一个规范化的数据库，用于事务处理，但具有许多用于报告和分析的额外索引。这是一种反模式-不要这样做。人们还是这样做，所以它仍然是一种模式。
设计数据库的大多数人都可以轻而易举地打出六打"这是其中的另一个"。这些是他们定期使用的设计模式。
并且这不包括使用和管理的管理和运营模式。
这是一位绅士的链接，他已经开发了数百个免费数据库模式。
http://www.databaseanswers.org/data_models/
也许如果我们必须快速构建数据库，这将为我们提供给定架构中的表和关系方面的起点。请记住，我们可能需要修改此起点。我发现它非常有用。
其次，《 SQL Server杂志》偶尔有一个名为"数据建模者"的专栏，它很有教育意义，通常包含给定系统的完整架构。
取决于我们所说的模式。如果我们正在考虑人员/公司/交易/产品等，那么是的，已经有很多通用的数据库模式可用。
如果我们在考虑Factory，Singleton ...那么我们就不需要这些了，因为它们对于DB编程来说太低了。
如果我们在考虑数据库对象的命名，那么它属于惯例类别，而不是设计本身。
BTW，S.Lott，一对多和多对多关系不是"模式"。它们是关系模型的基本构建块。
AskTom可能是有关Oracle数据库最佳实践的最有用的单个资源。 (我通常只键入"问号"作为针对特定主题的google查询的第一个单词)
我认为用关系数据库来谈论设计模式确实不合适。关系数据库已经是问题的"设计模式"的应用(问题是"如何在保持数据完整性的同时表示，存储和使用数据"，而设计是关系模型)。其他方法(通常认为已过时)是"导航"和"层次"模型(而且我肯定还有很多其他方法)。
话虽如此，我们可能会认为"数据仓库"是数据库设计中某种程度上独立的"模式"或者方法。特别是，我们可能对阅读Star模式感兴趣。
查看此博客The Database Programmer。
他描述了一些数据库模式。
