Adr*_*zza 5 sql portability database-design
我一次又一次地看到这里和其他地方的人都主张避免使用SQL语言的非便携式扩展,这是最新的例子.我记得只有一篇文章说明了我要说的内容,而且我再也没有那个链接了.
您是否真的从编写可移植SQL并解雇您的方言的专有工具/语法中获益？
我从来没有见过有人在mysql上构建一个复杂的应用程序,然后说你知道什么只是peachy？让我们切换到(PostGreSQL | Oracle | SQL Server)!
-say-PHP中的公共库确实抽象了SQL的复杂性,但代价是什么？您最终无法使用高效的构造和功能,因为您可能永远不会使用假定的轻微可移植性.这对我来说就像教科书YAGNI.
编辑:也许我提到的例子过于狡猾,但我认为重点仍然是:如果你计划从一个DBMS转移到另一个DBMS,你可能无论如何都要重新设计应用程序,否则根本就不会这样做.
与大型企业打交道的软件供应商可能别无选择(实际上这就是我的世界) - 他们的客户可能只有一个数据库供应商产品的政策.错过主要客户是商业上的困难.
当您在企业内工作时,您可以从平台的知识中受益.
一般来说,DB层应该被很好地封装,所以即使你必须移植到一个新的数据库,这种改变也不应该是普遍存在的.我认为采用YAGNI方法进行移植是合理的,除非您有针对即时多供应商支持的具体要求.使其适用于您当前的目标数据库,但仔细构造代码以实现未来的可移植性.