SQL Server 数据库开发标准
我必须为我们的组织制定 SQL Server 及其接口代码的数据库开发标准。 使用的代码可以是从 .NET 代码到 VBScript 到 SQL Server 作业的任何代码。
有没有人有此类事情的良好链接？
我的快速列表如下：
1）命名约定
-- 存储过程 usp_AppName_SPName
-- 函数 usf_AppName_SPName
-- 索引 IX_TableName_IndexName
-- 表 AppName_TableName
-- 视图 VW_Name
2) 将权限分配给角色，而不是直接分配给用户或组
3) 将角色分配给组，而不是直接分配给用户
4) 使用最小权限
5）代码中没有内联sql，总是使用SP或函数
6) 使用显式事务
7) 只读事务（如果适用）
8) 始终使用解释计划来确保 sql 的性能。
我们还需要涵盖哪些其他内容？ 我确信有很多事情......
I have to develop database development standards for our organisation for SQL Server and any code that interfaces to it. The code used can be anything from .NET code to VBScript to SQL Server Jobs.
Does anyone have a good link for this kind of thing?
My quick list is follows:
1) Naming Conventions
-- Stored Procedures usp_AppName_SPName
-- Functions usf_AppName_SPName
-- Indexes IX_TableName_IndexName
-- Tables AppName_TableName
-- Views VW_Name
2) Allocation of permissions to roles, never directly to users or groups
3) Allocation of roles to groups, never directly to users
4) Use of minimal permissions
5) No inline sql in code, always use SP or Functions
6) Use of explicit transactions
7) Readonly transactions where applicable
8) Always use explain plans to ensure sql is performant.
What other things do we need to cover? I am sure that there are lots of things....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
由于我们正在讨论最佳实践，因此我会提出一些要避免的事情：
必要时（例如动态旋转）
表）
PS 顺便说一句 - 我正在做以上所有的事情；）
Since we are talking best-practices I'd throw in a few things to avoid:
necessary (such as for dynamic pivoting)
tables)
P.S. Btw - I am doing all of the above ;)
我发现以下内容非常有用：
http://www.ssw.com .au/ssw/Standards/Rules/RulesToBetterSQLServerDatabases.aspx
http://www.codeproject.com/KB/database/sqldodont.aspx
I found the following quite useful:
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLServerDatabases.aspx
http://www.codeproject.com/KB/database/sqldodont.aspx
还可以考虑使用多个模式。 使用 AppName.TableName 而不是 AppName_TableName，其中 AppName 是架构。 例如，AdventureWorks 示例就是这样做的。
Also consider using multiple schemas. Use AppName.TableName instead of AppName_TableName, where AppName is a schema. The AdventureWorks sample does this, for instance.
我必须立即对你的第一个项目提出异议。 虽然我知道很多人喜欢对存储过程、表等使用前缀，但我从未过多使用过该约定。 当您开始获得大量以“usp_”开头的存储过程，并且单击以展开 Management Studio 中的“Programmability\Stored procedures”文件夹时，导航起来可能相当笨拙。
相反，需要一个前缀来匹配逻辑功能集/功能组。 这些前缀的含义因应用程序或数据库而异。 然后，如果您想区分存储过程和表，请添加“_usp”要求作为后缀。
对于表：您希望命名约定中的某些内容能够区分应用程序数据（查找表）和用户数据。
I have to take issue with your first item right off the bat. While I know a lot of people like to use prefixes for stored procedures, tables, and the like, I've never had much use for that convention. When you start to get a lot of stored procedures that all start with "usp_", and you click to the expand the "Programmability\Stored Procedures" folder in Management Studio, it can be rather unwieldly to navigate.
Instead, require a prefix to match the logical feature set/functional group. What those prefixes are will vary by application or database. Then if you want to distinguish a stored procedure from a table, add your "_usp" requirement as a suffix.
For tables: you want something in your naming convention to distinguish between Application data (lookup tables) and User data.
SQL Server 中的角色和组不是同一件事吗？
其他一些...
避免在 WHERE 子句中使用 UDF
禁止在应用程序中直接使用 SQL
（始终使用 SP）
视图/过程/函数包括
修订历史和/或修订
日期
对于复制表
Aren't roles and groups the same thing in SQL Server?
A few others...
Avoid using UDFs in WHERE clauses
Disallow direct SQL in applications
(always use SPs)
views/procs/functions including a
revision history and/or revision
date
for replicated tables