今天听了MSDN的WebCast，是关于Entlib的数据访问的讲座，末尾我问了两个自己所关心的问题：

1. 在一个较大型的应用中，如果需要用到两套以上的数据库（如：SQL Server和Oracle），是否可以把需要的sql查询全部封装在存储过程里，这样就只需要一套访问代码了，有没有更好的方法解决这个问题？
2. 在数据库的主键的设立中（同时支持多种数据库）直接用GUID作为主键来得简单，但是在查询的时候影响性能的因素大不大，还有没有更好的解决方法？

以上两个问题，由于时间的关系吧，微软的工程师解答的比较简略，第一个应该需要针对具体的应用来考虑，但是第二个问题，性能影响肯定是有的，但是影响大不大呢，带着这个问题，我做了这个小试验。

注：如果您有更好的建议不防贡献出来大家探讨探讨^_^！

测试环境：

• Dell笔记本电脑 迅驰1.5G
• Win XP professional
• 512MB DDR RAM
• SQL Server 2000 个人版

测试方法：

• 建立有10个字段的数据库[test_GUID]，使用GUID作为主键，以及其他常用的字段类型，模拟现实中的使用情况，建表的SQL代码如下：
  
• 建立有10个字段的数据库[test_IIDD]，使用IIDD作为主键，以及其他常用的字段类型，模拟现实中的使用情况，建表的SQL代码如下：
  
• 可以看到，第一个表使用全局唯一标识(GUID)来作为主键，而第二个表使用普通numeric（类似Int型）的数据类型来作为主键，关于GUID这里做一个小小介绍：
  
• 分别运行如下两个SQL语句对两个表分别插入10万条语句，我所关心大数据量的情况下的效果，所以不要怪我开始点选择10万条数据的情况^_^。
  
• 开始测试，测试代码及显示结果如下：
  
• 可以看到在10万条数据的情况下，普通Select查询的时候效率影响还不大
  
• 这可如何是好，GUID在没有where子句的聚合运算时吃大亏了
  
• 如结果所示，效果很不理想
  
• 上面的测试七和测试八在返回值方面不尽相同造成一些微小的差别这个可以忽略（因为我测试了在相同返回值的情况下差别是很小的）
• 可以看出在以GUID作为主键的表中加一个时间类型或是Int类型的索引可以弥补以GUID作为主键带来的性能损失。

总结：

此次测试由于时间的关系，测试的比较片面也很肤浅，还望能有高手把不足和疏漏的地方进行补充和改进，在这次测试后我想我还会做更多的关于性能方面的测试，有精力再做吧。

此次测试就只得出这么一点肤浅的东西，希望没有浪费您宝贵的时间^_^！

精彩评论：