ORMフレームワークをよく知っている場合、SQLは重要ですか？[閉まっている]

私はSQLに真剣な経験はなく、LINQの代わりにSQLを書くことさえ嫌いです。ORMには十分満足しています。

雇用主とセクターの観点から、SQLを知ることは重要ですか？習得する必要がありますか？ORMフレームワークよりも純粋なSQLを好む企業は、プログラミングの世界で「恐竜」ですか？

これは多くのプログラマーに説明するのは難しいです。なぜなら、基本的な SQL しか知らないなら、ORMの松葉杖よりも実際に多くの利点を与えないからです。より高度なSQLの概念は、しかし、ちょうどそのアプリケーションとの間の差の重要な一部であり、作業している対アプリケーションの高品質（特に、高速かつ信頼性の高いです）。

他の誰かがあなたのためにデータベースを設計していると思います。なぜなら、SQLを知らずにそれを行うことは、見た目を超えているからです。しかし、それらに対してのみ開発している場合でも、ORMがまだ不十分であるか、まったくしない傾向があるすべてのことの一部のリストを以下に示します。

• 再帰クエリおよび/または階層クエリ
• オプションのパラメーター（特に範囲述部に変換する）
• ユーザー定義のデータ型
• プラットフォーム固有のタイプ（SQL階層IDおよびTVP、Oracle配列、ネストされたテーブルなど）
• バッチの挿入/更新/更新/削除
• インデックスヒント
• ロックヒント（特に更新ロックとダーティリード）
• エラー処理
• 外部結合-結果セットはOOPモデルにうまくマッピングされず、多くのORMには独自のクエリ言語がありますが、これはSQL自体を知ることに似ています。
• ストアドプロシージャとUDF、特にインラインUDFとCROSS APPLYクエリによるモジュール化
• データを複数のテーブルにステージングするためのOUTPUT / RETURNINGの使用
• 効率的なページングクエリ
• ウィンドウ関数に基づいたクエリ（行番号、ランク、パーティション）

リストはどんどん続きます-これらの多くは、初心者DBAがしたことのないことであり、初心者の開発者は聞いたことすらありませんが、大規模なアプリでは非常に重要です。

ORMは、本当に退屈な SQLコードの高速化に非常に優れています。つまり、すべての反復CRUDとマッピング、およびその他の配管コードです。したがって、ORMを使用することはまったく恥ずかしくなく、悪意のある人の話を聞かないでください。しかし、あなたは間違いなく学ぶ必要があります。もちろん、マスター SQL でさえも、ORMがその重みを引いていないときに、生のDBコマンド/クエリにドロップダウンする準備ができています。

絶対に！SQLは今でもデータベースの共通語であり、ORMで多くのことをするかもしれませんが、ORMが下す決定とそれらが生成するSQLを理解するにはSQLを理解する必要があります。また、カスタムSQLやストアドプロシージャにも関係することがたくさんあります。申し訳ありませんが、無料のランチはありません。

はい、まだSQLを知っている必要があります。ORMは非常にリークの多い抽象化であり、SQLの全機能へのアクセスを提供しません。以下のためにおもちゃのアプリケーションあなたは、限られたSQLの知識を持つOKかもしれません。エンタープライズアプリケーションの場合、ORMから適切なパフォーマンスを得るには、データベースを理解する必要があります。また、アプリケーション言語よりもSQLの方がはるかに簡単に実行できる非常に多くのタスクがあります。私は、Javaプログラマーが1時間でSQLでコーディングできるようなことをするためのコードを書くのに何日も費やすのを見てきました。SQLの知識は、リレーショナルデータベースを使用するアプリケーションを作成する人にとって非常に貴重です。

SQLスキルは、今日のITスキルを持っている必要があります。LINQは、Microsoft専用のテクノロジーです。SQLの使用法は、Webおよびクライアント/サーバーアプリケーションの開発を超えています。SQLが苦手な場合、データベースをモデル化してETLを実行することはできません。Data Warehous製品用にORACLEおよびSQL Serverで使用されるSQLダイアレクトを習得する必要はないかもしれませんが、標準SQLを知っている必要があります。SQLの基本は簡単で、開始するための資料が山ほどあります。

SQLデータベースとやり取りする場合は、ORMが生成しているSQLを理解する必要があります。SQLデータベースに固有の概念を理解する必要があり、ORMができないことを理解する必要があります。ORMは生活を楽にします（そして、そうではなく、多くの場合あなたは恐竜であるとみなされます）。

SQLの学習を拒否する場合、ORMの有無にかかわらず、SQLデータベースに触れるビジネスはまったくないため、別のタイプの作業を見つける必要があります。

私は非常に頑固なORMファンであり、ORMの利点を長年説教しており、ORMがSQLに勝る理由について多くのことを述べてきました。

しかし...

SQLは現実の世界では完全かつ完全に必要であり、すべての開発者がSQLについて十分に理解している必要があることを認めなければなりません。

SQLプロシージャは、ほとんどすべての場合でORMよりも高速です。ほとんどの場合、ORM出力を楽観的にすることもできますが、SQLプロシージャのすぐ後に出力されます。

場合によっては、必要な結果を得るためにいくつかの強力なSQLが必要になります。これらのモンスタークエリは、SQLプロシージャで作成するのが簡単で高速です。

ほんの2ビットです。

ORMが作成している複雑なものを最適化する必要があるときが来ます。その時点で、通常、分解する非常に複雑なクエリがあります。基本を学んだことがない場合、高度なものでSQLの学習を開始するにはどうすればよいでしょうか？始めることすら理解できません。SQLを理解している人の手にあるORM-優れたツール。ORMは、SQLをまったく知らない人の手に渡ります。災害が起こるのを待っています。

データベースを理解する上でSQLが重要である理由の1つは、アプリケーションプログラマーがデータセットの観点から自然に考えないことです。ただし、データベースが効率的に動作する唯一の方法は、セット単位です。ORMを使用する前に、セットで考える方法を学ぶ必要があります。

私は、ORMフレームワークでクエリを手動で強制する場合が多くあります。そして、ほとんどが独自のクエリ言語を持っていますが、それらはすべてsqlに触発されており、コードはsqlに変換されます。
したがって、SQLを直接記述していない場合でも、基本レベルを超えて理解します（ただし、データベースにアクセスするだけであれば、ストアドプロシージャ、トリガーなどの記述について学ぶ必要はないでしょう）。生成されたコードを理解し、必要に応じて微調整するのに十分な言語を知っている必要があります。

質問についてお話しする前に、最初に少し紹介します。ORMが大好きです。そして、私はSQLが嫌いです。ORMが大好きなのは、SQLが持つユーザーフレンドリーではない混乱を隠し、データベースを扱うための優れた言語統合された方法を提供するからです。

ただし、SQLには多くの利点があり、大きな利点は精度であると認めざるを得ません。クエリを実行するだけで、基になるデータベーススキーマの詳細な知識がなくても、SQLクエリの複雑さについて議論することができます。したがって、SQLを使用するとき、私は常に警戒し、コンポーネントの複雑さがどこに向かっているのかを常に直感します。

一方、ORMを使用する場合、データベース統合の容易さに圧倒され、データベースがあることさえ文字通り忘れてしまいます。これは何度も私を台無しにしました。過去に何度も、私は無邪気に見えるORMメソッドを呼び出してきました。これは、舞台裏で大規模で恐ろしいデータベース結合を呼び出し、パフォーマンスを破壊します。

だからこそ、真実はその中間にあるのです。私はORMの使用が大好きで、これからも続けていきますが、もっと注意して、常にORMメソッド呼び出しの意味を（SQLレベルで）調べる必要があります。抽象化レイヤーの意味を知ることは、このビジネスにおける純粋な金であり、抽象化の使用を正当化します。それ以外のことは、自分を徒歩で撃つようなものです。

ビルドしているアプリケーションを介してのみデータベースと対話することが必要な場合は、おそらく必要ないでしょう。一部の小規模企業または開発チームでは、サポートが必要になる場合があります。クライアントのデータベースに接続し、いくつかのsqlステートメントを実行して、データで何が起こっているかを確認する方がはるかに簡単です。

優れた成熟したORMであっても、生成されたSQLで何が起こっているかを理解できれば、非効率的なSQLを出力し、生活をずっと楽にする状況に陥るのは避けられません。つまり、ORMに非常に精通していて、選択したDBにプロファイラーを使用する方法を知っている場合、「作成するまで偽造する」ことができます。

これらすべてのタイプの質問に対する答え（「Xを知る必要があるか？」）は、「初めて必要になったときに、必要に応じて学習する」というものです。

しかし、物事を効率的に行う方法に気付いていない、または学ぶ意欲がないため、物事を効率的に行わないというtrapに陥らないことが重要です。

この特定のケースでは、たとえば、プログラムにバグがPostCountあり、ユーザーテーブルのフィールドが不正確になることがあることに気付いた場合はどうしますか。

バグを修正したら、すべてのユーザーのPostCountを更新する必要があります。どうやってやるの？

これを行うためにORMを使用して小さなスクリプトを記述する場合、非常に非効率的です。非常に単純なSQLクエリで十分です。

これらの状況はかなり一般的であるため、上記のtrapに陥ることを恐れています！

はい、まだSQLが必要です。

「古い」何かがどういうわけか考慮に値しないという仮定にジャンプしないでください。いわゆる「レガシー」テクノロジーとは、時の試練に耐えた後もまだ存在しているテクノロジーです。私たちは王のコンピューターを「レガシー」とは呼ばず、失敗し、なくなった。

あなたが私に尋ねると、私の銀行はおそらくメインフレームでIBMを使用しているのでしょうか、それともIBM iですか？絶対ではありません。これらは、堅実で実績のある真のテクノロジーです。推測すると、彼らは主にDB2 SQLを使用しています。今月のファッショナブルな言語で開発されたソフトウェアよりも、そこでお金を信頼するほうがずっと幸せです。

恐竜はこの地球上で、私たち人間が住んでいたよりもずっと長く続きました。そして、もしあなたがジュラシックパークを読んだら（そう、本は映画よりも優れています）、あなたに尋ねます。「恐竜」を過小評価して噛まないでください。;-)

私が経験したことのないゲームや（主に統計的な）研究は別として、データベースへのアクセスと操作は、誤った決定が非常に大きなパフォーマンスヒットにつながる数少ない分野の1つであるようです。私はコード内のより強力なデータベース抽象化を強く信じており、データベース操作をプログラミング言語に結び付けて、言語のすべてのツール（型チェック、構文チェック、好きなものすべて）を提供するlinqを信じていますあなたのプログラミング言語）まだあなたが望むことをするのに十分な力を与えている間、絶対に素晴らしいです。残念ながら、それはまだ常に機能するとは限りません。つまり、抽象化レイヤーの最適化が間違っていて、結果がマイクロ秒ではなく秒、または秒ではなく分を待っている場合があります。これらは非常に目立つ時間であるため、それらを最適化する必要があります。そうしないと、アプリケーションが「機能」しません。パフォーマンスがアプリケーションの最大の問題になります。つまり、金属に近づき、手で最適化する必要があります。

大きなデータセットを操作する場合、手作業で行う場合はたとえば3ミリ秒かかり、抽象化レイヤーで処理できるようにする場合は100ミリ秒かかるという点に到達したら、必ず、抽象化レイヤーで処理させてください。 30倍遅くなりますが、それでも（おそらく、ほとんどのアプリケーションでは）十分に高速です。ただし、状況の現実は、200ミリ秒の応答時間がある手で最適化されたソリューションを見ているとき、および抽象化レイヤーがそれを処理するとき、アルゴリズムは「ちょうど」10回のパフォーマンスヒットを取るので、 2秒の遅延。それから、それほど高速ではなく、痛々しいほど遅くなるので、かなり気になります。ことを見て、リレーショナルデータベースソリューションがうまくスケールしません。、2、3年でこれが解決されるとは思わない。これは、大規模なデータベースに関してはかなり長い間ベアメタルに取り掛かる必要があることを意味します。さもないと、アプリケーションが非常に遅くなり、競合他社に耐えられなくなります。