是否可以为 MySQL 和 PostgreSQL 编写 SQL 脚本?
我想编写一个 SQL 脚本,该脚本将在默认安装的 MySQL 或 PostgreSQL(分别为 5.5 版和 9.0 版)上运行。这可能吗?
我几乎可以通过在脚本开头添加 SET SESSION sql_mode='ANSI'; 并使用标准 ANSI 查询来完成此操作,但该行对于 PostgreSQL 无效。我可以告诉 PostgreSQL 在出现错误时继续,但最好有一个运行时没有错误的脚本。
I'd like to write a single SQL script that will run on a default installation of either MySQL or PostgreSQL (versions 5.5 and 9.0, respectively). Is this possible?
I can almost do it by adding SET SESSION sql_mode='ANSI';
to the start of the script and using standard ANSI queries, but that line isn't valid for PostgreSQL. I could tell PostgreSQL to continue on errors, but It'd be nice to have a script that runs without error.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
尝试使用条件注释:
PostgreSQL 将忽略它,MySQL 将运行它。有关详细信息,请参阅文档。
更新:如果您想包含仅在 PostgreSQL 上运行但不在 MySQL 上运行的命令,您可以利用 PostgreSQL 支持嵌套注释而 MySQL 不支持的事实。以下示例显示了如何使用它:
但这可能会使文件非常难以读取。
Try using conditional comments:
PostgreSQL will ignore it, MySQL will run it. For more information see the docs.
Update: If you want to include commands that are run only on PostgreSQL but not on MySQL, you can exploit the fact that PostgreSQL supports nested comments, and MySQL doesn't. The following example shows how this could be used:
But this would probably make the file very difficult to read.
是的。
请下一个问题!
...
好吧,严肃地说,这是完全可行的,但是你必须意识到每个人所做的事情不同。例如,如果您需要在 PG 中使用
bytea
,但在 MySQL 中使用BLOB
,那么正确编码/转义将会非常有趣。然后还有全文搜索之类的东西。 PG 内置了它,MySQL 只内置了一种表类型(MyISAM,糟糕的表类型),而且语法完全不同。这甚至不涉及字符集和排序规则。如果您将自己限制在简单的 CRUD 操作上,那么您可能就可以开始了。哎呀,如果您正确完成了工作,您也可以使用相同的代码与 SQLite 和 MSSQL 对话(当切换到 ANSI 模式时)。
一旦您变得相当复杂,您的代码将至少需要了解底层数据库来解决小的行为和语法差异。重要的是,您的大部分查询可以在底层数据库之间共享,而无需任何修改,如果您正确构建它们。
Yes.
Next question, please!
...
Okay, in all seriousness, it's totally doable, but you have to be aware of the things that each does differently. For example, if you need to use a
bytea
in PG, but aBLOB
in MySQL, you're going to have a really fun time getting the encoding/escaping correct. Then there's things like fulltext searching. PG has it built in, MySQL has it built in to only one table type (MyISAM, the sucky one), and the syntax is totally different. And this doesn't even touch character sets and collations.If you limit yourself to simple CRUD operations, you're probably good to go. Heck, if you've done your job right, you can also probably use the same exact code to talk to SQLite and MSSQL (when switched to ANSI mode).
Once you even get moderately complex, your code is going to need to at least be aware of the underlying database to work around the small behavior and syntax differences. The important part is that the majority of your queries can be shared between underlying databases without any modification whatsoever if you construct them properly.
我认为您正在进行一对一的功能比较。我没有阅读整个链接,但我认为它可能对您的探索有用。
http://troels.arvin.dk/db/rdbms/
I think you are in for a one-by-one feature comparison. I didn't read the whole link but I think it might be usefull in your quest.
http://troels.arvin.dk/db/rdbms/
在服务器中而不是在脚本中设置模式:
http://dev.mysql.com/doc/refman /5.5/en/server-sql-mode.html
显然,在脚本中您将使用两者都接受的功能的最低共同支配因素。 MySQL 也被认为拥有最符合标准的解析器,但这并不意味着它实际上意味着它会做任何事情(这是一个很好的方法,因为脚本都可以工作,但行为可能完全不同)。 Postgresql 也不兼容“ansi”。它可能是最接近的,但它有很多独特的东西。似乎不是一个理想的方式。
ORM 正在努力做同样的事情——消除痛苦。
Set the mode in the server not in the script:
http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html
Obviously in the script your going to have use the lowest common dominator of features that both accept. MySQL is also known to have the most standard compliant parser but that does not mean it actually mean it will do anything (Good way to get Gotcha'd since the scripts will both work but behaviour may be totally different). Postgresql is not 'ansi' compliant either. It may come the closest but it has plenty of things unique to itself. Does not seem like an ideal way.
ORM's work hard at doing this same kind of thing - taking the pain out of it.
添加
不带条件(?)解决了 ulogin php 库安装问题。
如果您已经在命令行上创建了
use database;
,那么添加它也很有帮助。Adding
Without the conditions (?) solves the ulogin php library install problem.
Also helpful to add
use database;
if you already created it on the command line.