关系数据库devise模式？
devise模式通常与面向对象的devise有关。
是否有创build和编程关系数据库的 devise模式 ？
许多问题肯定有可重用的解决scheme。
例子包括表格devise，存储过程，触发器等模式。
是否有类似于martinfowler.com这样的模式的在线存储库？
模式可以解决的问题的例子：
- 存储分层数据（例如，具有1：1键和差异的typesvs多个表的单个表…）
- 用variables结构存储数据（例如，generics列vs xml vs分隔列…）
- 使数据非规范化（如何以最小的影响做到这一点等等）
Martin Fowler的Signature系列中有一本书叫做Refactoring Databases 。 这提供了重构数据库的技术列表。 我不能说我已经听到了很多数据库模式的列表。
我还强烈推荐David C. Hay的数据模型模式和后续的元数据地图 ，这个地图build立在第一个基础之上，而且更加雄心勃勃。 前言本身就是有启发性的。
Len Silverston的数据模型资源手册系列第1卷包含通用的数据模型（员工，账户，运输，采购等）， 第2卷包含行业特定的数据模型（会计，医疗保健等）， 第3卷提供了数据模型模式。
最后，虽然本书表面上是关于UML和对象build模，但Peter Coad的UMLbuild模提供了一个“原型”驱动的实体build模过程，从任何对象/数据模型有4个核心原型的前提开始
这是一个已经开发了几百个免费数据库模式的绅士的链接。
http://www.databaseanswers.org/data_models/
也许如果你必须快速build立一个数据库，这将给你在一个给定的模式中的表和关系的起点。 请记住，您可能需要修改这个起点。 我发现它非常有用。
其次SQL Server杂志有一个偶尔列“数据build模师”这是非常教育，并经常包含一个给定的系统完整的模式。
devise模式不是可重复使用的解决scheme。
根据定义，devise模式是可重复使用的。 他们是你在其他好的解决scheme中发现的模式。
一个模式不是可以重复使用的。 然而，你可以按照模式实现你的羽绒devise。
关系devise模式包括以下内容：
-
使用外键的一对多关系（主 – 细节，父 – 子）关系。
-
与桥表的多对多关系。
-
可选的一对一关系在FK列中用NULL来pipe理。
-
星型模式：维度和事实，OLAPdevise。
-
完全标准化的OLTPdevise。
-
维度中的多个索引search列。
-
包含一个或多个应用程序使用的PK，描述和代码值的“查找表”。 为什么要有代码？ 我不知道，但是当他们必须被使用时，这是一种pipe理代码的方法。
-
单表。 [有人把这叫做反模式; 这是一个模式，有时是坏的，有时候是好的。]这是一个有许多预先join的东西的表格，违反了第二和第三范式。
-
arrays表。 这是通过在列中有一个数组或一系列值来违反第一个正常forms的表。
-
混合使用的数据库。 这是一个数据库规范化的交易处理，但有很多额外的索引进行报告和分析。 这是一个反模式 – 不要这样做。 人们无论如何都这样做，所以它仍然是一个模式。
大多数devise数据库的人可以很容易地拿出六打“这是另外一个”。 这些是他们定期使用的devise模式。
这不包括使用和pipe理的pipe理和操作模式。
看看这个博客 – 数据库程序员 。
他描述了一些数据库模式 。
Joe Celko的书很适合这类东西，特别是“聪明人的SQL”。 他对常见问题有一些创新的解决scheme，其中大部分是可重复使用的devise模式。
AskTom可能是Oracle数据库最佳实践中最有用的资源。 （我通常只input“asktom”作为特定主题的谷歌查询的第一个字）
我认为用关系型数据库说devise模式并不合适。 关系数据库已经是一个“devise模式”应用于一个问题（问题是“如何表示，存储和使用数据，同时保持其完整性”，devise是关系模型）。 其他方式（通常被认为是过时的）是Navigational和Hierarchical模型（我不知道有很多其他模式）。
话虽如此，您可能会认为“数据仓库”是数据库devise中的一种单独的“模式”或方法。 尤其是，您可能对阅读Star模式感兴趣。
经过多年的数据库开发，我可以说有一些没有去的问题，你应该在开始之前回答一些问题：
问题：
- 你想在未来使用另一个DBMS？ 如果是，那么不会使用当前DBMS的特殊SQL的东西。 删除应用程序中的逻辑。
不使用：
- 表名和列名中的空格
- 表和列名称中不包含Ascii字符
- 绑定到特定的小写或大写。 不要使用只有小写和大写不同的两个表或列。
- 对于“FROM”，“BETWEEN”，“DELETE”等表或列名称不使用SQL关键字
recomendations：
- 使用NVARCHAR或等效的Unicode支持，那么你没有问题的代码页。
- 给每一列一个独特的名字。 这使得它更加容易select列。 如果每个表格都有一个“ID”或“名称”或“描述”列是非常困难的。 使用XyzID和AbcID。
- 使用资源包或等于复杂的SQLexpression式。 这使得切换到另一个DBMS变得更加容易。
- 不要在任何数据types上强制转换。 另一个DBMS不能有这种数据types。 例如Oracle没有一个SMALLINT只有一个数字。
我希望这是一个很好的起点。
你的问题有点含糊，但我想UPSERT可以被认为是一种devise模式。 对于没有实现MERGE语言，可以使用多种方法来解决问题 （如果存在合适的行， UPDATE ;否则INSERT ）。
取决于你的意思是一个模式。 如果你在思考人员/公司/交易/产品等，那么是的 – 有很多通用数据库模式已经可用。
如果你正在考虑Factory，Singleton …那么不需要 – 因为它们对于DB编程来说太低了，所以你不需要这些。
如果你正在考虑数据库对象的命名，那么它就属于惯例的范畴，而不是本身的devise。
BTW，S.Lott，一对多和多对多的关系不是“模式”。 它们是关系模型的基本组成部分。
这本书看起来很有趣
Title: Data Patterns By: Microsoft Corporation Publisher: Microsoft Press Pub. Date: December 21, 2004 Print ISBN-13: 978-0-7356-2200-5
