|
六、不要给“性别”列创建索引
首先，我们必须了解索引是如何加速对表的访问的。你可以将索引理解为基于一定的标准上对表进行划分的一种方式。假如你给类似于“性别”这样的列创建了一个索引，你仅仅是将表划分为两部分：男和女。你在处理一个有1,000,000条记录的表，这样的划分有什么意义？记住：维护索引是比较费时的。当你设计索引时，请遵循这样的规则：根据列可能包含不同内容的数目从多到少排列，比如：姓名 省份 性别。
七、使用事务
请使用事务，非凡是当查询比较耗时。假如系统出现问题，这样做会救你一命的。一般有些经验的程序员都有体会-----你经常会碰到一些不可预料的情况会导致存储过程崩溃。
八、小心死锁
按照一定的次序来访问你的表。假如你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。假如你（不经意的）某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。假如锁定顺序没有被预先具体的设计好，死锁是不太轻易被发现的。
九、不要打开大的数据集
一个经常被提出的问题是：我怎样才能迅速的将100000条记录添加到ComboBox中？这是不对的，你不能也不需要这样做。很简单，你的用户要浏览 100000条记录才能找到需要的记录，他一定会诅咒你的。在这里，你需要的是一个更好的UI，你需要为你的用户显示不超过100或200条记录。
十、不要使用服务器端游标
与服务器端游标比起来，客户端游标可以减少服务器和网络的系统开销，并且还减少锁定时间。
十一、使用参数查询
有时，我在CSDN技术论坛看到类似这样的问题：“SELECT * FROM a WHERE a.id='A'B，因为单引号查询发生异常，我该怎么办？”，而普遍的回答是：用两个单引号代替单引号。这是错误的。这样治标不治本，因为你还会在其他一些字符上碰到这样的问题，更何况这样会导致严重的bug，除此以外，这样做还会使SQL Server的缓冲系统无法发挥应有的作用。使用参数查询，釜底抽薪，这些问题统统不存在了。
十二、在程序编码时使用大数据量的数据库
程序员在开发中使用的测试数据库一般数据量都不大，可经常的是最终用户的数据量都很大。我们通常的做法是不对的，原因很简单：现在硬盘不是很贵，可为什么性能问题却要等到已经无可挽回的时候才被注重呢？
十三、不要使用INSERT导入大批的数据
请不要这样做，除非那是必须的。使用UTS或者BCP，这样你可以一举而兼得灵活性和速度。
十四、注重超时问题
查询数据库时，一般数据库的缺省都比较小，比如15秒或者30秒。而有些查询运行时间要比这长，非凡是当数据库的数据量不断变大时。
十五、不要忽略同时修改同一记录的问题
有时候，两个用户会同时修改同一记录，这样，后一个修改者修改了前一个修改者的操作，某些更新就会丢失。处理这种情况不是很难：创建一个timestamp字段，在写入前检查它，假如答应，就合并修改，假如存在冲突，提示用户。
十六、在细节表中插入纪录时，不要在主表执行SELECT MAX(ID)
这是一个普遍的错误，当两个用户在同一时间插入数据时，这会导致错误。你可以使用SCOPE_IDENTITY，IDENT_CURRENT和 @@IDENTITY。假如可能，不要使用@@IDENTITY，因为在有触发器的情况下，它会引起一些问题（详见这里的讨论）。
|
| 共3页: 上一页 [1] 2 [3] 下一页 |
评论加载中…
