データベースへのアクセスにjavaまたはpythonを使用しているとします。それでは、時間の浪費と見なされ、SQL内で使用されているデータ構造とオブジェクトの種類を学習する必要はありませんか？

ソフトウェア業界についてお答えください。どのような場合にそのようなことを知っておくとよいかを教えてください。

私はそのようなことを学ぶ必要はないと言っている誰かとの議論があります。

数年前、私はSQLデータベースのしくみを明らかに知らなかった誰かによって書かれたアプリケーションに取り組みました。修正すべき問題のレポートを受け取りました。常に遅くなっていたメインステータスの概要ページが非常に遅くなり始め、レンダリング中にサーバースクリプトの実行タイムアウト（3分）に達していました。システム内のクライアントの数が増えるにつれて、ステータスページをレンダリングする時間が二次的に増加するように見えました。

問題に気付くのに時間がかかりませんでした。つまり、ページが2つの異なるテーブルのデータを統合するクエリを使用し、どちらにもインデックスがなかったということです。各テーブルのサイズはクライアントの数に応じてO（n）で増大していたため、クエリは最初のテーブルの各行をフェッチしていたため、クエリの実行にO（n ^ 2）時間かかっていました。それらを比較するために2番目のテーブルのすべての行をフェッチしていました。

問題の解決には数分かかりましたが、SQLデータベースの仕組みを理解している人なら誰でも同じくらい迅速に対応できたでしょう。元の作者はそうしなかったので、完全に不十分な解決策を残しました。

このような恐ろしい間違いをしないためには、テクノロジーが（少なくとも一般的には）どのように機能するかを理解する必要があります。

実際にデータベースにアクセスして、デバッグプロセスの一部として直接クエリを実行する必要がある可能性を考慮してください。あなたがいる場合、これまでのことをやってしまう、あなたは間違いなくあなたの特定のデータベースが構成されているすべてのデータベース技術について、どのように知りたいでしょう。多分それは起こりません。しかし、そうである場合（そして私の経験では、いつかは常にそうです）、その知識が必要になります。

ただし、なんらかの理由でデータベースに直接アクセスする必要がないと仮定します。コミュニティによって提示されたすべてのベストプラクティスと一貫した方法でORMを使用しているとしましょう。あなたは可能性があり、データへのすべての主要なミス/ボトルネック/非効率WRTせずにパフォーマンスアプリを作ります。しかし、基礎となるデータベースを本当に理解していなければ、なぜあなたが自分のやり方で物事を行っているのか本当に理解できません。さらに悪いことに、あなたは本当に特定のユースケースにベストプラクティスがどのように適用されるかを理解します。これらの事実は、最適なソリューションを作成していることに疑問を投げかけるはずです。あなたの解決策はうまくいくかもしれませんが、実際の自信をもって「これが最良の解決策である」とは言えません。あなたがそれを言うことができないならば、あなたはあなたの会社の目に大きな資産ではありません、そしてあなたがそれを言って、あなたが間違っているならば、それはあなたにとってひどく見えるでしょう。

私があなたのテックスタックの基本を学んでいないという哲学的な論争だけでなく、私はあなたのスタックを上から下まで毎日知るための具体的な理由を扱います。私の会社には、膨大な量のデータを処理する巨大なモノリスがあります。物事はうまくモデル化されていますが、アプリケーションには何十もの種類のオブジェクトがあり、それらの間の関係は外部キーと関連テーブルの驚くべきウェブです。率直に言って、SQLを調べずにアプリに飛び込むだけの場合（すべてがアプリで正しくモデル化されており、ORMを使用し、そのORMのベストプラクティスを確立している場合）、この他のビットを指定してこの情報を取得する方法を理解しますここでは、ほとんど不可能に近い雑用になることがあります。しかし、DBに飛び込むことができれば、各モデルのすべてのフィールドを確認し、テーブル間の接続をたどることができます。ある部分から別の部分へのパスを把握し、クエリでテストしてから、ORMを介して迅速かつ効率的に実行するための適切なモデルを見つけます。ベアメタルSQLに高いレベルの快適さがなければ、会社の資産の半分にはなりません。

ある程度まで

ソフトウェア開発者はおそらくデータベースをクエリして更新する必要があります。DBの動作方法を理解することは、不適切なクエリや非効率な結合などを回避するために重要です。あなたは可能性があるパーティションIRデータベースをインデックスを追加する場所を決めることができ、専用のDBAを持っていますが、どちらかではない中小企業では、それを頼りにしていない、常に大規模なものではないことができます。

しかしながら

インデックスとは何か、どのように使用するかを知っておく必要がありますが、プロベイビーはインデックスが内部でどのように機能するかを知る必要はありません。内部実装の詳細はそれだけです-実装の詳細。

SQLクエリプランを確認し、それに応じてコードを作成する方法を理解する（つまり、DBが公開するAPIの一部）。それを達成するために使用する内部アルゴリズムとデータ構造を知っていますか？ない。そんなに。アナロジーとして、私はファイルをディスクに保存することのパフォーマンスへの影響を知っているべきです。ファイルシステムの実装方法を気にする必要はありません。

しかし、しかし

明確なコメントが示すように、質問がDBアクセスを理解することと、ORMやその他のコードの抽象化に完全に依存することの比較である場合、答えは圧倒的に「はい、DBアクセスを知っている必要があります」です。すべてのプロジェクトがORMを使用または使用できるわけではなく、ORMは特定のタスク（レポート、一括挿入など）に理想的ではありません。

時間は絶対に価値があります！フルスタックの開発者になると、付加価値ソリューションを効率的に作成できます。通信障害やサイロ化された開発を頻繁に目にしました...開発時間を3倍にし、品質を半分にします。

結局のところ、スキルが多ければ多いほど、価値も高くなります。

車について何も知らないと公言したら、私のブレーキを修理してもらえますか？私はそうは思いません。

データベースは、プログラミングでの作業に慣れているデータ構造とは著しく異なります。それらには、独自の奇妙さ、特異性、およびあなたがそれらを理解していない場合にアプリケーションパフォーマンスであなたを食い込ませる他のものがあります。

私はこの「データベースを知る必要がない」という考え方を持つ人々に出会いました。それらのほとんどは、データベースをスプレッドシートにすぎないと見なし、結果として恐ろしいほどパフォーマンスが悪いアプリケーションを生成します。

つまり、データベースが内部でどのように動作するかを知る必要はありません。

論理的なものを知ってください。テーブル、インデックス、ビューなど。

特定の DBMSがこれらのものを処理する方法の実装の詳細に巻き込まれないでください。それらはすべて互いに（そして時にはそれ自体のバージョン間で！）異なる方法で実行するため、一般的な「概要」が最適です。

あなたは絶対に知る必要があります。たとえば、データベースに日付が格納されている場合は、期待できる精度の種類を知る必要があります。タイムスタンプをDATEフィールドに格納する場合、データベースが値を最も近い秒（さらに悪い場合は最も近い日）に切り捨てるかどうかを知っている必要があります。また、NUMBER(9,2)列からの値は浮動小数点変数に格納する必要がありますが、aの値NUMBER(15,0)は整数として格納できることも知っておく必要があります。また、OracleのCHAR列には指定された長さまで空白が埋め込まれ、列には空白が埋め込まれないなど、少し奇妙なことを知っておくと便利VARCHAR2です。そして、それらのLONGデータ型は実際には数値ではなく可変長文字列を格納します。

すべてのデータベースには癖があり、それらが何であるか（または少なくとも何を探すか）を知っている必要があります。

内部で物事がどのように機能するかを理解すると、パフォーマンスとストレージに関する考慮事項についてクエリをデバッグするのに役立ちます。

たとえば、範囲クエリは、Bツリータイプのインデックスを使用するとパフォーマンスが向上します。また、結合を実行するときに、HASHまたはMERGE結合を使用するかどうかに関するヒントをクエリエンジンに追加できます。また、物理的な側面では、1つのデータベースのテーブルを異なる物理ディスクパーティションに分散して、ヘッドの競合を最小限に抑えることができます（SSDを使用する場合でも適切です）。

最初に、SQLが何であり、何でないかを明確にする必要があります。SQLは、リレーショナルデータベース内のデータにアクセスして操作するために使用されるクエリ言語およびデータ操作言語です。しかし、データベースのスキーマとデータオブジェクト（テーブル、列、インデックス、制約）は「SQL」ではなく、SQLはデータのクエリと操作に使用できる言語の1つにすぎません。

リレーショナルデータベースを効果的に使用するには、テーブル、列、データ型、主キー、外部キー、およびインデックスを理解する必要があります。また、プロジェクション、フィルター、結合などのクエリの基本を理解する必要があります。正規化の基本を理解する必要があります。

ただし、これらのいずれも、原則としてSQLに触れる必要はありません。GUIデザイナーでデータベーススキーマを設計したり、PythonのSqlAlchemyや.netのLinqなどの他の言語でクエリや更新を記述したりできる場合があります。これらの言語はSQLよりも純粋にリレーショナルモデルを表現していると主張する人もいます。

したがって、理論的にはあなたの友達は正しいです-SQLを学ぶ必要はありません。しかし、リレーショナルデータベースがどのように機能するかを学ぶ必要があります。SQLは単なる構文なので、SQLを学ぶのは非常に簡単です。

必ずしも必要ではありませんが、SQLを知っていると非常に便利です。これは、別の変換レイヤーを必要とせずに、SQLで任意のデータベースを直接クエリできるためです。また、すべてのチュートリアル、書籍、および例ではSQLを使用しているため、習得を避けることは困難です。

シリアル番号がデータベースに10桁の10進数として格納され、Javaで32ビット整数に読み取られるという問題に遭遇しました。これは、2Gを超える最初のシリアル番号に到達するまで問題なかったため、Javaの32ビット符号付き整数では表現できませんでした。DBデータ型を理解することで、この問題を回避できた可能性があります。