多数据库支持
最近老板要我作一个东东,他要支持四种主流的数据库:Sqlserver   sybase   oracle   mysql,不知大家有什么好的建议,希望能提出来。。。
------解决方案--------------------参考.net的 DataAdapter
------解决方案--------------------使用3层,可以很好的支持N种数据库
------解决方案--------------------把数据访问层分离成二层即:数据库访问层,用于与实际的数据库打交道,数据访问层,用于获取数据   
 设计时可参照 “工厂模型”
------解决方案--------------------工厂
------解决方案--------------------比如说更改配置文件就能从Oracle切换到SqlServer 
 -------------------------------------------------- 
 在数据库访问层里把需要支持的数据库访问方法都写全,数据访问层根据用户配置使用工厂方法选择使用不同的数据库访问对象   
 但是发现微软没有提供Mysql和Sybase的Provider,自己去实现难度太大了 
 --------------------------------------------------- 
 去MySql和SyBase公司网站上去找,他们都已经做好了,不用你操心的,呵呵。
------解决方案--------------------参考PETSHOP吧
------解决方案--------------------不用反射机制来搞数据库迁移,是很难做到灵活的。 
 你们老大的观点是什么。
------解决方案--------------------用工厂模式做就行了 
             根据传入的数据库名字 去选择相应的处理方式 
 要代码我可以发一份给你
------解决方案--------------------不用反射?搞数据库动态迁移? 
 学习一下,你们是如何解决的? 
 如果你们老大,说这个东西慢,那叫他去搞啊,技术老大本来就搞这些东西的,不然干吗啊
------解决方案--------------------直接用微软的企业库
------解决方案--------------------企业库,也是用反射吧
------解决方案--------------------参照Petshop 4.0 
------解决方案--------------------要么用工厂模式,要么用ODBC
------解决方案--------------------Connection.XML     
     <Sybase> 连接字符串..... </Sybase>  
     <Oracle> 连接字符串..... </Oracle>  
     .... 
     <MSSQL> 连接字符串.... </MSSQL>    
     <UsingConn> 正使用的数据库 </UsingConn>    
  <!--每种数据库的SQL会有所不同,所以用XML文件存储-->  
 SQLStr.XML 
      <XXX查询>  
         <Sybase> select ........ from  </Sybase>  
         <Oracle> select ........ from  </Oracle>  
         <MSSQL> select ........ from  </MSSQL>  
      </XXX查询>  
      <XXX更新>  
         <Sybase> Delete from ...... </Sybase>  
         <Oracle> Delete from ..... </Oracle>  
         <MSSQL> Delete from ....... </MSSQL>  
      </XXX更新>  
     ........ 
------解决方案--------------------以上的方法支持N多都行啊    
   要想再添加就这样: 
      <FoxPro> 数据库连接串.... </FoxPro>     
   SQL语句 
      在后面增加一个 
         <FoxPro> .......... </FoxPro>      
  是不是很方便呢?代码都不用改
------解决方案--------------------给老板说,让他自己去做吧。
------解决方案--------------------在ADO.NET中如果不进行深层的加工,你做不到数据库平台独立性。至少每一种数据库的ADO.NET模型的参数处理方式可能不同(我想大概这是微软的严重失误)。为了能让程序员可以直接写sql脚本,而且可以实现跨数据库平台,我负责的项目牺牲了很多东西。基本思路是定义一个sql的变体,然后实现一个针对每一种ADO.NET提供程序的包装,由这个包装负责解析这个变体为符合后台数据库要求的sql脚本。比如,我规定的sql中的参数必须是“?{ParameterName}”,后台提供程序分别将这个格式的参数转换为“?”、“@ParameterName”或者其他格式。对于聚合函数,所有的数据库平台基本上都符合sql标准,而对于其他函数,则使用自定义的函数取代。当然还要求程序员们必须写符合sql标准的查询。当然还有很多其他的措施,在此不一一列举。