编写可移植的SQL是否有必要或方便？ [英] How necessary or convenient is it to write portable SQL?

问题描述

一次又一次地，我看到过这里和其他地方的人都主张避免对SQL语言的非移植性扩展，这个是最新的例子。我记得只有一篇文章说明了我要说的话，而且我没有那个链接。

你是否真的受益于编写可移植的SQL并解雇你的方言的专有工具/语法？

我从来没有看到有人在mysql上创建一个复杂的应用程序，然后说你知道什么是只是桃子？我们切换到（PostGreSQL | Oracle | SQL Server）！

-say- PHP中的公共库会抽象出SQL的复杂性，但是花费多少钱？您最终无法使用高效的结构和功能，因为您最有可能永远不会使用的推测的可移植性。这听起来像是我的教科书YAGNI。

编辑：也许我提到的例子太骇人听闻了，但我认为还有一点：如果你正在计划从一个DBMS到另一个DBMS，你可能会重新设计应用程序，或者你根本不会这样做。

解决方案

处理大型企业的软件供应商可能没有选择（确实是我的世界） - 他们的客户可能会有仅使用一个数据库供应商的产品的策略。错过主要客户的商业难题。

当您在企业内部工作时，您可以从平台的知识中获益一般来说，DB层应该被很好的封装，所以即使你不得不移植到一个新的数据库，这个变化不应该是普遍的。我认为采用YAGNI方法进行移植是合理的，除非您有即时多厂商支持的具体要求。使其与您当前的目标数据库配合使用，但仔细构建代码，以便将来可移植。

Time and again, I've seen people here and everywhere else advocating avoidance of nonportable extensions to the SQL language, this being the latest example. I recall only one article stating what I'm about to say, and I don't have that link anymore.

Have you actually benefited from writing portable SQL and dismissing your dialect's proprietary tools/syntax?

I've never seen a case of someone taking pains to build a complex application on mysql and then saying You know what would be just peachy? Let's switch to (PostGreSQL|Oracle|SQL Server)!

Common libraries in -say- PHP do abstract the intricacies of SQL, but at what cost? You end up unable to use efficient constructs and functions, for a presumed glimmer of portability you most likely will never use. This sounds like textbook YAGNI to me.

EDIT: Maybe the example I mentioned is too snarky, but I think the point remains: if you are planning a move from one DBMS to another, you are likely redesigning the app anyway, or you wouldn't be doing it at all.

解决方案

Software vendors who deal with large enterprises may have no choice (indeed that's my world) - their customers may have policies of using only one database vendor's products. To miss out on major customers is commercially difficult.

When you work within an enterprise you may be able to benefit from the knowledge of the platform.

Generally speaking the DB layer should be well encapsulated, so even if you had to port to a new database the change should not be pervasive. I think it's reasonable to take a YAGNI approach to porting unless you have a specific requriement for immediate multi-vendor support. Make it work with your current target database, but structure the code carefully to enable future portability.

这篇关于编写可移植的SQL是否有必要或方便？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！