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

cheyo车油 2005-02-26 09:31:23
举一个例子,SQLServer的触发器可以帮你节省项目中的很多代码,节省你的开发时间

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

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

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

...全文
106 10 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
10 条回复
切换为时间正序
请发表友善的回复…
发表回复
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
  • 打赏
  • 举报
回复
我觉得应该要确保可移植性,因为真正好的工程都是用少量的代码去实现的!
代码太多,不易维护!

67,550

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧