6.6w+
社区成员
- 全部
代码简洁与数据库移植性冲突时，你选择哪一个？
举一个例子，SQLServer的触发器可以帮你节省项目中的很多代码，节省你的开发时间
但SQLServer的触发器难以移植到其他数据库中。 除了触发器，存储过程等也是同样的情况。
那么这个时候你会选择哪一个？
是要仍然使用触发器，但破坏他的数据库可移植性？ 还是保留数据库可移植性，多写些代码？
但SQLServer的触发器难以移植到其他数据库中。 除了触发器，存储过程等也是同样的情况。
那么这个时候你会选择哪一个？
是要仍然使用触发器，但破坏他的数据库可移植性？ 还是保留数据库可移植性，多写些代码？
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
wadsunglow 2005-02-26
显然是多写些代码，来得到移植性的提高
kaymo 2005-02-26
保证移植性
jFresH_MaN 2005-02-26
显然是多写些代码，来得到移植性的提高
就想现在的很多的框架和设计模式，不都是以代码的复杂度换取可重用性吗
就想现在的很多的框架和设计模式，不都是以代码的复杂度换取可重用性吗
vssivl 2005-02-26
建议全部用SQL,不要用存储过程和触发器,用SQL可以很快作出自动化的程序,可以节省程序员大量的时间,把效率问题交给数据库吧.
ymm 2005-02-26
多写点代码,到什么数据库都能用
禽兽v5 2005-02-26
一般来说,
工业型企业的项目业务逻辑很复杂，那么都需要很复杂的sql语句，不然程序效率很低。这样最好建议客户不要考虑数据库移植问题。
如果是普通企业的管理系统，那么连sql都没什么必要，直接hibernate + hql 搞定。
工业型企业的项目业务逻辑很复杂，那么都需要很复杂的sql语句，不然程序效率很低。这样最好建议客户不要考虑数据库移植问题。
如果是普通企业的管理系统，那么连sql都没什么必要，直接hibernate + hql 搞定。
飞行的兔子 2005-02-26
的确,多写些代码保持可移植性是很值得的.建议用标准的SQL语言.
cao_zp 2005-02-26
数据库移植是很常见的。没一年用户就要升级了。
还是做好准备
还是做好准备
kingxyz777 2005-02-26
当然是注重可移植性，为了以后版本升级，软件的二次开发都是有用处的
congbailing_914 2005-02-26
我觉得应该要确保可移植性，因为真正好的工程都是用少量的代码去实现的！
代码太多，不易维护！
代码太多，不易维护！
