私はプロダクションマシン用にPostgreSQLを、H2はDAOレベルでユニットテストを行い、アプリケーションレベル用にはJava/JDBCで作業しています。プリペアドステートメントへのパラメータとしてのSQL配列 - 移植性
SQL配列を使用してデータベースの一括照会を実装したいと考えています。しかし、2つのデータベースが期待する構文は異なるようです。 Postgresのでは、それはH2で
SELECT * FROM mytable WHERE id=ANY(?)
あり、それは私がSQLを標準化することになったと考え
SELECT * FROM TABLE(id CHARACTER VARYING=?) NATURAL JOIN mytable
です！私は実際の基準を読んで行くことにしましたが、明らかにそれにはお金を払わなければなりません...ばかげた！
データベース間で移植可能な別の方法がありませんか？
標準化されていますか？データベース間の移植性？ハ！あなたは面白かった。私はPostgreSQLで配列を見つけただけですが、StevenはSQL99に入っていることを示しています。私は、構文が（彼らは通常、これらの事でかなり良いしているように私は、PostgreSQLを推測すると思います）規格であるかわからないけど、クエリでほとんどどこでも同じように動作するはずです：
はselect * from mytable where id in (?)
あなたが使用したいですコンマで区切られたリストをidのプレースホルダに入れてください。リストのサイズは、idです（もちろん、そのサイズはデータベース固有のものになります）。
データベースシステム全体で一貫している特定の標準があります。多くの場合、これは実装のベースラインです。それぞれのシステムはそれぞれ独自の方法でこれらの標準を構築します。
すべてのシステムで一貫性のある何かを思いつくことを考えようとするのは絶対的な悪夢です。これを行う最善の方法は、自分が行っていることをその基準にあるものに限定していることを確認することです。これ以上何もない。たとえば、集約関数を使用するなど、それを超えていれば、あなた自身で実行できます。
数週間前、私はユニットテストのためにdev/testとSQLiteでPostgreSQLを使用するシステムを実装しようと考えていました。メモリ内のSQLiteデータベースを使用すると、統合テストのスピードアップにつながると思いました。その部分は真実でしたが、PostgreSQLとSQLiteの間の機能の不一致は、いくつかの頭痛を引き起こしました。いくつかの異なるもの（私もNHibernateを使用していた）を介して戦った後、私はあきらめて、その考えを放棄した。
物語のモラル？可搬性/標準化はあまり意味がありません。あなたがやっていることのすべてにおいてあなたが使っているものに一貫していてください。多くの悲しみを救うでしょう。
まあ、私はあまりにも狂っていないものに固執する限り、私は大丈夫だろうと思う。上で動作する構文があります。 –
いくつかのウェブサイトでは、配列がSQL99で標準化され、SQL2003で展開されているため、Postgres拡張ではないと主張しています。つまり、構文は機能します。ありがとうございました:-) –
@Steven：私はPostgreSQLの配列を見つけたばかりで、最近の標準であることに気づいていませんでした。つまり、私はデータベースがWebブラウザやCコンパイラよりも標準よりも遅れていることに気が付いています:) –
あまりにも... :-( –