8

オブジェクト指向言語でSQLを操作するのが面倒なことの1つは、SQLステートメントを文字列で定義する必要があることです。

私がIBMメインフレームで作業していたとき、言語はSQLプリプロセッサを使用してネイティブコードからSQLステートメントを解析したため、ステートメントは文字列を難読化せずにクリアテキストSQLで記述できました。たとえば、COBOLにはEXECSQLがあります。 ...END-純粋なSQLステートメントをCobolコードに埋め込むことができるEXEC構文構造。

<pure cobol code, including assignment of value
 to local variable HOSTVARIABLE>    

EXEC SQL
       SELECT COL_A, COL_B, COL_C
       INTO :COLA, :COLB, :COLC
       FROM TAB_A
       WHERE COL_D = :HOSTVARIABLE
END_EXEC

<more cobol code, variables COLA, COLB, COLC have been set>

...これにより、SQLステートメントが非常に読みやすくなり、エラーをチェックできます。EXEC SQL .... END-EXECトークンの間には、インデントや改行などの制約がないため、好みに応じてSQLステートメントをフォーマットできます。

この例は単一行の選択用であり、複数行の結果セットが予想される場合、コーディングは異なります（ただし、v。読みやすい）。

したがって、Javaを例にとると

  1. 「古いCOBOL」アプローチを望ましくないものにした理由は何ですか？SQLだけでなく、このアプローチを使用すると、システムコールをはるかに読みやすくすることができます。それを組み込み外国語プリプロセッサアプローチと呼びましょう。

  2. SQL用の組み込み外国語プリプロセッサは実装に役立ちますか？Javaコード内にネイティブSQLステートメントを記述できることの利点はありますか？

編集

私は、オブジェクト指向言語のSQLが先祖返りだと思うかどうか、そしてそうでない場合は、それを改善するために何ができるかを本当に尋ねています。

4

7 に答える 7

4

Java にはすでに埋め込み SQL の標準があり、それはSQLJと呼ばれています。

そうは言っても、私はそれが実際に使用されているのを見たことがありません。また、最新のツールを使用して、それが本当にオプションであるかどうかもわかりません. 標準が登場したとき、オラクルは大々的にそれを求めましたが、私はそれがつるに死んだと思います.

于 2010-01-08T08:57:03.030 に答える
2

SQL ドメインには、Java および .NET 用の「組み込み言語プリプロセッサ」に似たものがすでにあります: http://ibatis.apache.org/

また、人々が通常行っていることは、 Hibernateのような本格的な ORM を使用して、SQL を抽象化することです。

これらのツールは、SQL 文字列を Java コード自体に格納することはできませんが、同様の目的を果たします。個人的には、コード自体に SQL 文字列を格納するメリットはないと思います。すべての SQL を特定のファイルにきちんと記述しておくと、SQL の再利用性と保守性が向上します。必要に応じて SQL を文字列として使用できますが、これは通常、最後の手段です (ORM ツールがユース ケースに対して適切な抽象化を持っていない場合)。

編集: SQL とコード (オブジェクト指向であろうとなかろうと) を混在させることは脆弱であり、望ましくないと思います。クエリを一元的に保存する場所を用意する方がはるかに優れています。これがiBATISのアプローチです。

于 2010-01-08T08:58:03.510 に答える
1

適切な IDE を使用して、このような機能を回避できます。たとえば、IntelliJ IDEA は注入言語と呼ばれる機能をサポートしています。文字列リテラル内に必要な言語でコードを記述し、コードの強調表示、補完、ナビゲーション、およびその他のサービスを使用できるようにします。ここで詳細を読むことができます: http://blogs.jetbrains.com/idea/2009/03/user-defined-language-injection/

于 2010-01-16T21:30:31.530 に答える
1

Hibernate などのオブジェクト リレーショナル マッピング ツールは、理論的にはこの種の問題を軽減します。「理論的に」;）

また、Grails を使用できる場合は、SQL ステートメントを読みやすくする素晴らしい複数行の文字列を記述できると聞いています。

于 2010-01-08T08:57:53.937 に答える
0

SQLJのようなアプローチの主な欠点の 1 つは、プリプロセッサがデータ アクセス ロジックに最新の IDE ツールを使用できないことです。Eclipse、NetBeans、またはIntelliJ IDEAなどの優れた IDEでは、これはプリプロセッサに対する強力な反論です (これについてはブログでも書いています)。

それまでの間、 Eclipse XtextやJetBrains MPSなどの DSL ツールは、Java 言語自体を拡張するのにまだ苦労しています。これは、COBOL で使用されていたようなものを実現するためです。

1 つのオプションは、実際には SQL ではありませんが、ジョブにjOOQのような内部 DSL を使用することです。

于 2014-04-05T16:23:38.037 に答える
-2

これを行うための最も簡単で最も頭がおかしい方法は、単純に SQL を文字列としてコードに含めることです。

何かのようなもの

   Statement s = new Statement("Select * from wherever");

それはあまり洗練されていないかもしれませんが、うまくいきます。欠点は、コンパイラが SQL 構文をチェックできないことです。少し良い解決策は、パラメトリックテンプレートを指定するPrepaired Statementsです。したがって、次のようなことができます。

PreparedStatement s = connection.prepareStatement("Select * from wherever where state = ?");

そうすれば、実行時に準備済みステートメントを作成するとすぐに、JDBC 接続で例外がスローされるはずです。したがって、コードが初めて機能する場合は、常に機能するはずです。

次に、後でコードでパラメーターを変更する必要がある場合は、次のようにします。

s.setString(1, "CA");

Microsoft には、 LINQと呼ばれる .net 用の組み込みクエリ言語があります。データベースの場合、LINQ to SQLを使用すると、クエリをコードに直接埋め込むことができます。

于 2010-01-08T09:10:37.353 に答える