SQL 数组作为准备好的语句的参数 - 可移植性答案

【问题标题】：SQL Arrays as parameters to prepared statements - portabilitySQL 数组作为准备好的语句的参数 - 可移植性
【发布时间】：2011-06-03 21:15:45
【问题描述】：

我在生产机器上使用 PostgreSQL，在 DAO 级别上使用 H2 进行单元测试，在应用程序级别上使用 Java/JDBC。

我想使用 SQL 数组来实现对我的数据库的批量查询。但是，这两个数据库所期望的语法似乎是不同的！在 Postgres 中是

SELECT * FROM mytable WHERE id=ANY(?)

在H2中是

SELECT * FROM TABLE(id CHARACTER VARYING=?) NATURAL JOIN mytable

我以为 SQL 应该是标准化的！我决定去阅读实际的标准，但显然你必须为此付费……荒谬！

我是否错过了另一种可跨数据库移植的方式？

【问题讨论】：

标签： sql arrays postgresql h2

【解决方案1】：

标准化？跨数据库的可移植性？哈！你搞了个笑话。我只遇到过使用 PostgreSQL 的数组，但 Steven 表示它们在 SQL99 中；我不知道哪种语法是标准的（我猜是 PostgreSQL，因为它们通常对这些东西非常好）但是 IN 查询应该在任何地方都可以正常工作：

select * from mytable where id in (?)

您将在占位符中使用逗号分隔的 id 值列表，并且您必须注意 ids 列表的大小（当然，该大小将是数据库具体）。

【讨论】：

一些网站声称数组是在 SQL99 中标准化并在 SQL2003 中扩展的，因此不会是 Postgres 扩展。也就是说，您的语法确实有效。谢谢:-)
@Steven：我只在 PostgreSQL 中遇到过数组，并不知道它们是最近的标准。也就是说，我发现数据库比网络浏览器和 C 编译器更落后于标准:)
不敢相信我错过了 IN 语法。希望我能阅读标准以找出答案！ :-p 谢谢。
其实这样不行！它尝试将 ARRAY 值视为标量并检查相等性，即 id = "1,2,3" 这不是我想要的。 :-/ 它恰好适用于单个值...
@Steven：不知道你的意思。有什么东西在背后将你的 IN 更改为 = 吗？

【解决方案2】：

有些标准在数据库系统中是一致的。在许多情况下，这是实施的基准。然后，每个单独的系统都以自己的方式构建在这些标准之上。

甚至考虑尝试提出在所有系统中都一致的东西绝对是一场噩梦。做到这一点的最佳方法是确保您将所做的事情限制在这些标准中。而已。如果您超出此范围，例如使用聚合函数，您就只能靠自己了。

几周前，我想尝试实现一个系统，在该系统中我在开发/测试中使用 PostgreSQL 并在单元测试中使用 SQLite。我认为拥有一个内存 SQLite 数据库可以帮助我加快集成测试。虽然那部分是正确的，但 PostgreSQL 和 SQLite 之间的功能差异引起了许多麻烦。在经历了几件不同的事情之后（我也在使用 NHibernate），我放弃并放弃了这个想法。

故事的寓意？可移植性/标准化意义不大。在您所做的所有事情中使用的内容保持一致。你会省去很多痛苦。

【讨论】：

嗯，我想只要我坚持不太疯狂的事情，我会没事的。我得到了在上面起作用的语法。