代码简洁与数据库移植性冲突时,你选择哪一个?

cheyo车油 华为 开发组长/高级工程师/技术专家  2005-02-26 09:31:23
举一个例子,SQLServer的触发器可以帮你节省项目中的很多代码,节省你的开发时间

但SQLServer的触发器难以移植到其他数据库中。 除了触发器,存储过程等也是同样的情况。

那么这个时候你会选择哪一个?

是要仍然使用触发器,但破坏他的数据库可移植性? 还是保留数据库可移植性,多写些代码?

...全文
81 点赞 收藏 10
写回复
10 条回复
切换为时间正序
当前发帖距今超过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 搞定。
回复
飞行的兔子 2005-02-26
的确,多写些代码保持可移植性是很值得的.建议用标准的SQL语言.
回复
cao_zp 2005-02-26
数据库移植是很常见的。没一年用户就要升级了。
还是做好准备
回复
kingxyz777 2005-02-26
当然是注重可移植性,为了以后版本升级,软件的二次开发都是有用处的
回复
congbailing_914 2005-02-26
我觉得应该要确保可移植性,因为真正好的工程都是用少量的代码去实现的!
代码太多,不易维护!
回复
发帖
Java EE
创建于2007-09-28

6.6w+

社区成员

J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
申请成为版主
帖子事件
创建了帖子
2005-02-26 09:31
社区公告
暂无公告