SQLを記述する必要はまだありますか？

最新のほとんどの言語用の非常に多くのORMツールがありますが、それらをサポートする言語/環境で、プログラムでSQLを記述および実行するためのユースケースはまだありますか？もしそうなら、なぜですか？

わかりやすくするために、プログラマがSQLを知る必要があるかどうか、またはデスクトップにSQLツールを用意する必要があるかどうかについては質問していません。ORMではなく、コード（または構成など）に含める理由を具体的に尋ねています。

• 手続き型コードを書くよりも、データをクエリするSQLの方が快適です。
• ORMは見た目は美しいですが、いくつかの重要な領域で恐ろしく遅いSQLを生成します。
• ORMを介して利用できない/利用できないRDBMSによって公開される機能を利用する必要があります。
• 入力するたびにSELECT * FROM...、神は子猫を殺します。そして、あなたは子猫が嫌いです。
• ORM、OOP、または最新の言語を使用していません。

複雑なSQLの作成

ORMは基本的なものに最適です。ただし、複雑な状況では、SQLを作成する必要があります。

つまり、要するに、SQLの必要性は最も確かであり、常にそうであり続けるでしょう。

• 視聴回数
• トリガー
• 制約
• パッケージ（SSIS、DTSなど）
• 実行フローを正確に制御する必要があるときはいつでも

ORMは、データベースの構築、調整、自動化を支援しません。すべてのことを行ったら、データベースと対話する代替方法を提供します。

承知しました：

• 通常、ORMは多くをカプセル化しますが、最終的には舞台裏で何が起こるかを知っておく必要があります。これは、パフォーマンスとスケーラビリティにとって重要です。アプリケーション内ではあまりSQLを記述しませんが、SQLまたはDDLがどのように見えるかは大体知っています。
• 多くの場合、直接SQLは読み取り専用クエリを作成するのに適しています。ORMクエリ言語で作成する方がはるかに簡単で、結果セットを制限することもできます（たとえば、「select id from .....」）。
• ORMは、SQLからユーザーを遠ざけるべきではありません。DBクライアント（mysqlクライアントなど）でアドホッククエリに直接SQLを使用します。非常に優れた統一されたインターフェイスとグループ化機能を提供します。

ORMは、一般的なリレーショナルDB実装とOO言語機能間のインピーダンスの不一致により存在します。それらは単なる橋ですが、ほとんどの人はSQLを冷蔵庫の中のリンブルガーチーズのように扱います。

SQL /ストアドプロシージャ/ビューをファーストクラスのインターフェイスとして扱うのではなく、常にORMまたは他の抽象化されたデータアクセスレイヤーを使用するという正当な理由がある場合は、SQLに触れずに済ませた方がよいでしょう。

実際には、最終検証のためにデータベースを照会するために少なくともSQLを必要としないpure-ORMプロジェクトを見たことはありません。

ORMは、プログラマツールボックスのツールです。彼らには独自の問題があります。以下に例を示します。

• SQLを制御できません
• n + 1の問題に苦しむ

自分が何をしているのかわかっている場合、ORMを効果的に使用して、CRUDタイプコードの多くを置き換えることができます。ただし、複雑なものにはそれほど効果的ではなく、パフォーマンスチューニングが難しく（パフォーマンスはオブジェクトをエミュレートするのではなく、データベース設計の重要な部分の1つであることは知っています）、それらはまったく恐ろしく、危険な人の手にありますSQL自体を理解したり記述したりしないでください。

また、ORMを使用して複雑なレポートを効果的に行うのは簡単ではないことも指摘したいと思います。さらに、簡単な粗雑なもので単純なSQLを学ばない場合、レポート用の複雑なSQLを作成できるポイントにどのように到達しますか？レポートの必要性がなく、多くの場合非常に複雑なものが必要なアプリケーションで作業したことはありません。

ORMは、ほとんどの場合BIまたはETLプロセスに役立ちません。また、データベース管理クエリや監査テーブル内の情報を検索したり、特定のデータベース変更セットを元に戻したりするのにも役立ちません。SQLで最も効果的に行われている多くのことがあります。データベースを照会するアプリケーションは、エンタープライズ環境でデータベースを照会する必要があるもののごく一部です。

また、ORMを使用して何かを行う方法については、ポスターがSQLで行う方法をすでに知っている多くの質問もあります。新しいことを学ぶのは良いことですが、元の方法よりも実際の利益が得られずに余分な時間と労力を費やしている場合（そしてしばしばパフォーマンスの実際の損失）、それらを現在「ファッショナブル」である以外に使用しているのはなぜですか？

クライアントは、レポート、エクスポート、データダンプなどのデータを返すための迅速で簡単なクエリを望み、プログラム全体が開発されるのを待ちたい場合があります。

また、優秀なSQLプログラマーは、私が使用したどのORMよりも、より高速で効率的なSQLを常に記述できます。また、多くの人がORMがストアドプロシージャを指しているだけであることがわかりました。ORMの利点を実際に無視すると、ORMは複雑なプロセスには向いていません。

また、Oracleのようなデータベースを非常にリッチで強力なプロシージャ言語で使用すると、「プログラム」を必要とせずに多くのことができます。Oracle上のPL / SQLは、非常に高速で効率的です。

データベースを自分で使用したい場合は、はい。私が使用しようとしたORMのほとんどは、十分ではなかったか、データベースをカバーしていませんでした。また、カバーされていないカスタムクエリをどのようにトラブルシューティングまたは記述しますか？

トリガーとストアドプロシージャの作成には引き続き必要です。ストアドプロシージャは、現在のところ好まれないかもしれませんが、状況によっては非常に便利です。SQLは、特に毛深い複数テーブルの結合にも必要になる場合があります。

はい、SQLの記述を避けることができます。しかし、代わりにHQL（またはLinq、またはDQL ...）を書くことになります！

真剣に、私はORMの大ファンであり、ほとんどの場合、純粋なSQLの使用を避けることができると思います。しかし、ORMは1つの大きな抽象化であり、すべての大きな抽象化がリークすることを覚えておく必要があります...

（ただし、N + 1の問題については、これは遅延読み込みに関連するものであり、ほとんどのORMツールにはeager-loadingを要求する方法があるため、その特定の問題を回避できます。）

ORMは、特定のポイントにのみ到達します。しかし、複雑な結合、サブクエリ、ユニオン、マイナス、分析関数など、非常に複雑なクエリを実行する必要がある場合があります。それがSQLを必要とするときです。しかし、すべての単純なクエリをORMに任せる場合、どのように複雑なクエリを記述することになっていますか？

コードに記述しなくても、データベースサーバーへのターミナルアクセスがあるときに使用できると便利です。

また、プログラミングを困難にしているもののほとんどは、私たちが設定している制限内で働くことです-私たちはしばしば古いコードや古いバージョンのデータベースで作業しており、私たちがどんな言語でも最新のORMライブラリをインストールする機会がありません一緒に働く。そのような状況では、任意のツールが必要になります。

残りの時間は、CRUDにSQLを必要としないかもしれませんが、SQLには、単純なSELECT、INSERT、UPDATE、および基本的なJOINクエリよりもはるかに多くのことがあります。それを使って非常に賢いことをすることができ、頻繁に使用することはないかもしれませんが、それらが何であるかを知ることは有用です。

ますます、ポストSQLの世界にいると思いますが、クラウドサービスのほとんどは非SQLテーブルストレージを使用しており、単純なCRUDタイプの作業にはSQLの全機能は不要です。しかし、それはそれを理解することに価値がないという意味ではありません。

また、もちろん、現在のものがあまり大きくない場合、誰かがより良いORMシステムを書くのに十分な知識が必要です。彼らがSQLを知っていればそれは彼らを助けるでしょう...

大規模なWebアプリケーションを構築することは完全に不要であり、必要以上にストレスと時間の浪費を引き起こす可能性があります。その理由は、大規模なアプリでは、メモリの永続化レイヤー（RAM内）を使用する必要があるためです。このレイヤーは、頻繁に使用されるDBのメモリキャッシング部分です。

動作するメモリがあまりないモバイルデバイスなどで処理する必要がある場合、プログラムされているアプリケーションがモバイルデバイス、タブレットなどで「クライアント」またはスタンドアロンアプリとして実行されている場合SQLを使用するようなことは今でも一般的であり、重要です。なぜなら、デバイスのメモリは非常に小さく、多くのことをメモリにキャッシュできないからです。

私が書くSQLの複雑さと量は、ORMフレームワークを適切にフックするのに十分ではありません。

（もしそうなら、月に一回SQLを書く）

私は、ORMツールを使用する開発者を積極的に恐れるDBAを持つ多くの大企業に出会いました。

チューニングとパフォーマンスに関与しているのはDBAです。

そして、はい、ORMツールはこのようなことを行うことができますが、ストアドプロシージャ（SQL Server）のみを受け入れ、その中で何をしているのかを質問する場所を見てきました。

また、ORMツールはひどく乱用され、SQLを自分で記述するのと同じくらい貧弱なSQLを生成する可能性があります。

特筆すべき点は、DDLとデータベースの移行です。既存のものを壊さずに物事を更新するには、そのようなものを手縫いする必要がある場合があります。