SQL Server - 您的团队有哪些编码/开发规则？

上周我问了一个类似的问题，没有得到很好的答复，所以也许我没有以正确的方式提出问题。SQL Server - 您的团队有哪些编码/开发规则？

我想知道您的团队在编写T-SQL代码和数据库模式方面有哪些流程/政策/规则。这里有几个例子：

1) All foreign key columns should be indexed 
2) All primary key columns should be integer Identity 
3) All stored procedures/user defined functions need comments 
4) No underscores in T-SQL variable names

这些是我很好奇的东西。

谢谢！

来源

2010-04-26 Randy Minder

这真的是社区wiki的东西。 – 2010-04-26 11:21:26

他在石头上写规则，后来希望得到一大瓶白葡萄酒！除了格式化/样式/命名/源代码过程之外，只是坚持准则而不是绝对规则。您可能需要使用不同的PK（某天的非标识）或不需要FK上的索引等。 – 2010-04-26 11:37:08

不是真的。我们在某些较大的桌面FK上没有索引，因为我们从不删除或更新父值，或选择性较差。大多数情况下，但明白了原因。也就是说，我会使用3位代码本身来存储ISO货币代码（如CHF或GBP）的表格。而且你仍然需要对自然键的唯一约束

来源

2011-01-22 12:46:15 gbn

我不同意索引的所有外键。如果您拥有一个只有3个选项的主表的外键，那么在一个包含数百万行的表中，您会产生无谓的索引。从关键到数据的反向查找是不太可能的。

来源

2010-04-26 11:23:59 cjk

似乎＃1，＃2和＃3都是相当差的规则。索引外键并不总是必要的。当一个好的自然键存在时，创建一个代理键是没有意义的。评论不会编译，因此它们很容易与代码不同步，并可能欺骗读者。只有在绝对必要时才能使用它们。评论完成一条坚强而快速的规则比浪费时间更糟糕。

项目＃4是相当不错的。团队我曾一直更关心的事情，去实施的质量工作（例如良好的错误在所有存储过程的处理和存储过程做的只有一件事）

来源

2010-04-26 11:25:16

在处理数据库的30年中，我很少遇到真正的自然键。由于性能原因，代理通常比自然密钥更好。如果您拥有真正的自然键，则与子表相关的代理键和自然键上的唯一索引通常是性能最佳的选项。 – HLGEM 2010-04-26 15:26:36

SQL Server - 您的团队有哪些编码/开发规则？

回答

相关问题