Best practices for taking on the DBA role as a developer
今天看到一篇文章，有点想法，摘要转录如下（英文部分为原文，中文是我自己加的，推荐读原文）：
Best practices for taking on the DBA role as a developer
Problem
I
am an application developer and my company doesn't have a database
person on staff. Since I have a little bit of database knowledge, it
has now become my responsibility to perform the data modeling and
development work. What advice can you offer?
不知道别的地方如何，我所在的单位和大部分的小公司一样，并没有专门的数据库管理员，同样在程序开发团队里面，也没有对数据库（编程）比较精通的。我偶尔扮演数据库管理员的角色，其实就是执行几条简单的语句，自己明白我的水平其实不高，也不足以在程序开发时回答关于数据库部分的问题。因为个人原因，所以我倾向于做一个对数据库有所了解的应用程序开发人员。
Solution
If you find yourself in this situation, don't get overwhelmed. The forums found here at MSSQLTIPS.com
as well as the various SQL Server bulletin boards across the web are
great places to get answers to any problems that may be stumping you.
They are full of experienced SQL Server professionals who have probably
"been there, done that" and are eager to help.
If you're relatively inexperienced with databases in general and SQL Server specifically, here are a list of things I'd initially recommend:
1. Don't rely on your logic tier code to perform integrity checking - use constraints!
之前所写的程序里面，基本上把所有的外键和约束条件都放弃掉了，主要是在程序逻辑里面实现数据完整性，虽然没有遇到太大的问题（用程序实现，从表面上看起来似乎更简单），但是我也知道这么做是不正确的，至少不够专业。前两天讨论5G的代码规范的时候，居然有同事建议说可以使用中文的变量命名，.net的确可以支持，数据库的字段也可以直接用中文，不过我觉得实在是“丢不起人”。为什么老是有人想要“汉语编程”呢，我觉得就好像非要中西医结合治疗一样。
2. When you create constraints in your database, name them!
因为之前对于约束本就用的不多，所以这一条并没有什么特别的感觉，可能主要是考虑代码的可读性吧。
3. Normalize to third normal form. De-normalize when necessary.
“第三范式”，天啊，我得去查查，早就被忘到爪哇国去了。3NF大概就是说：Eliminate duplicative columns（消除冗余）、primary key（主键）、Remove subsets of data（移除子表）、foreign keys（外键）、Remove columns that are not dependent upon the primary key（移除与主键无关的列）。
4. Use stored procedures for data access.
虽然会写SQL的语句，不过存储过程的确写的不多，曾经照猫画虎的写了几个，这次5G倒是一个学习PL/SQL的好机会。
5. Avoid creating redundant indexes
不知道其他的项目如何，我之前倒是遇到一个缺少索引的，以至于影响数据库查询的效率。就我们目前的项目规模，我觉得稍微多几个index，应该不至于有太大的代价。清楚多余的索引，我感觉需要有专门的数据库管理员（专家）来分析。
6. Carefully consider whether you should use GUIDs as PRIMARY KEYs in your database.
在之前做数据转移的时候，发现没有id主键，而是采用联合主键的表比较麻烦，所以当时认为应该给所有的表都加上id主键，当然这个和GUID不完全是一回事儿；不过后来又觉得大部分情况下没有必要专门留一个id主键，这样可能会带来额外的开销，到现在还比较困惑
7. Make sure your tables have a clustered index.
这个我不太明白
8. Always stress test your queries BEFORE they go into production.
同样不明白，多少有点怀疑小规模的项目是否需要严格的压力测试
9. Determine a BACKUP strategy.
至少在目前的这个5G项目里面，并没有考虑到备份的问题；同样的，还有数据迁移。
10. Consider creating database unit tests
