データベースの抽象化—やり過ぎですか？

多数のデータベース抽象化レイヤーにさらされた後、私は、データにアクセスするための独自の異なるパラダイムを発明するすべてのライブラリーのポイントが何であるか疑問に思い始めています。新しいDALを取得することは、新しい言語をもう一度学習するように感じます。通常、やりたいことは、既に自分の頭に書いたSQLクエリを出力するようにレイヤーを説得することだけです。

そして、それは事後の読みやすさにさえ触れていない：

# Exhibit A:  A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
    .inner_join(db.ips_x_users.user_id == db.users.id)
    .select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)

# Exhibit B:  Another typical DAL
rows = db.ips_x_users
    .join(db.users, on=db.ips_x_users.user_id == db.users.id)
    .filter(db.ips_x_users.ip_addr == '127.0.0.1')
    .select(sort=~db.ips_x_users, limit=10)

# Exhibit C:  A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
             INNER JOIN users ON
                 (ips_x_users.user_id = users.id)
             WHERE ips_x_users.ip_addr = ip
             ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')

標準のSQL構文の何が問題になっていますか？特定の目的のために作成され、その目的に美しく適合します。たぶんそれは私だけかもしれませんが、スニペットCは最初の2つよりはるかに簡単に理解できます。名前が変更されたキーワードと構文のトリックはかわいいですが、IMOは、すぐに言えば、コーダーが行を簡単に取得できないようにします。

これはおそらく長い暴言のように思えましたが、ここには本当の疑問があります。すべてのDALは、実証済みのSQLを単に解析するのではなく、クエリ用の新しいDSLを発明しているように見えるため、異なる構文を使用する利点があるか、標準のSQL構文に欠陥があることを認識している必要があります。誰かが私がここで見落としているものを指摘してもらえますか？

一般的なSQL使用の最も基本的な問題は、SQLクエリが文字列であり、何らかの方法で別の言語から構成されていることです。これは、SQLインジェクションやその他の脆弱性やWTFの原因です（クエリには実際にはパラメーターがないため、サンプルの選択は非常に不適切です）。

次の問題は実際には当然の結果です。コードにSQLを記述しただけでは、コンパイラはそれについて何もできません。列名のタイプミスなどのエラーは、実行時にのみ発生します。これは基本的に、ソースコードにクエリの文字列表現だけが必要なわけではありませんが、すべてのfacepalm-bugsの95％を防ぐためにコンパイラが静的に分析できるものです。

そして、リレーショナルデータベースを言語のセマンティクスとプログラミングモデルにマップしようとすると、最後の問題が発生します。RDBMSはOOP（またはナビゲーションデータの取得）とうまく連動しません。実際、これはこれら2つを組み合わせた非常に恐ろしいアイデアですが、SQLデータベース（つまりORM）のすべてのオブジェクト指向DALの目的です。しかし、これらのすべての抽象化レイヤーはリークが非難されます。これが基本的にそれらの多くが存在する理由だと思います：あなたは彼らと仕事をしているので、あなたは彼らに欠陥があるのを見て、それを正しく行い、最終的に失敗するDALを書き始めました。

したがって、問題1と2はSQLを削除するDALを持つことを示唆していますが、問題3は1つ（少なくともOOPの場合）を持つ直接的な解決策がないことを示唆しているため、異なる長所と制限を持つDALの海が常に存在します。最後に、できることは、いくつかを慎重に選択してそれらに固執することだけです。

すべてのデータベースプラットフォームが同じSQL構文を受け入れるわけではないという明らかな事実を見落としているため、アプリケーション全体にSQLステートメントを埋め込むことは、すべてのデータベースプラットフォームで機能するとは限りません。複数のデータベースプラットフォームをサポートする必要がある場合、これらのSQLステートメントのほとんど（すべてではないにしても）を再考する必要があります。

SQLは、ポインタが10年前と同じ大きな変化を経験しているように感じます。SQLによる手動作業を排除し、より高い抽象化レベルに引き上げる試みが継続的に行われています。同じことが、何年も前にポインタと手動メモリ管理で発生しました。

作業は現在進行中であるため、多くの異なるアプローチが提案され、試行され、放棄され、統合されています。マニフェスト自体を希望する場合は、何らかの一般的なアプローチまたは業界標準の前に、より多くのことを見ると確信しています。

同じレベルでデータアクセスコードを操作し、アプリケーションコードを操作するときに適用するのと同じパラダイムを使用できる場合、確かに優位性が得られます。

簡単に言えば、単純化、敏g性、迅速性、これらが目標です。

ジョエルは10年前に素敵な記事を書いていました：建築宇宙飛行士にあなたを怖がらせないでください

まさにそうだと思います。パターンを見つけたので、自分のアプリケーションで抽象化レイヤーを使用していましたが、この方法は簡単でした。しかし、ソースコードのすべての行=>フルコントロールを知っていたのは私のDALでした。しかし、私のフレームワークを私のチーム/プロジェクト以外の人に使用することはお勧めしません。

そのようなものを使用する場合、その実装方法を知ることが重要です。つまり、ライブラリ/ツールの学習に多くの時間を費やす必要があります。それを学ぶ時間がない場合-使用しないでください。たとえ最初から非常に簡単に見えても。