経験豊富なプログラマは、データベースクエリを知っている必要がありますか?[閉まっている]


35

クエリの作成とデータベース設計の専門家でもある非常に多くのプログラマーがいます。

これは、専門のプログラマーまたはソフトウェアエンジニアになるための必須要件でしょうか?

類似の多くは、クエリとコードが開発されている方法でありますが、私の個人的な意見は、あるクエリが異なる持っているように見える構造よりもコードを、異なるアプローチによる同時に両方をマスターするのは難しいことができます。


2
「構造」とはどういう意味ですか?セマンティクスについて話している場合、「エキスパート」にとっては、新しいセマンティクスの種類を把握することは問題になりません。定義により。OTOH、データベースとクエリ言語にさらされている開発者はごく少数であり、残りの人はまったく気にしません。
SKロジック

3
これは誤った仮定だと思います。「クエリの作成とデータベース設計の専門家でもある非常に多くのプログラマがいます。」これらのことを熟知しているプログラマーは比較的少ない:DBA!= SE。
アシュリー

1
データベースクエリを書くのは本当に難しいですか?
キャプテンセンシブル

@ CaptainShakespeare、CRUDの操作を一度経験すると、本当にかなり難しくなります。いつか複雑なレポートを行うこと。次に、パフォーマンスチューニングクエリを確認します。
HLGEM

回答:


69

データベースクエリの作成がコア要件であるかどうかはジョブによって異なりますが、リレーショナルデータベースは現在のテクノロジではどこにでもあります。

そのため、データベースクエリの記述方法がわからないプログラマに会った場合、次の2つのいずれかを期待します。

  1. 彼らは一般的に未経験です。
  2. 彼らは別の分野(組み込みシステムなど)に高度に特化しており、それを学ぶ必要はありませんでした。

データベースクエリは、より標準的なプログラミング言語とは根本的に異なります。それらは代数的であり、リレーショナルデータで動作することを目的としていますが、C#またはJavaは必須であり、ディスク、メモリ、ユーザー入力などで動作します。

編集:私や他の人がコメントで指摘したように、経験豊富な開発者がデータベースクエリをよく知らないかもしれない正当な理由がいくつかあります:

  • 彼らのチームはORM / NoSQLを使用しました
  • チームにはDBプログラマーがいました
  • アプリケーションの複雑さはビジネスロジックにあり、DBクエリは簡単でした。
  • 彼らのチームは、一部のプログラマーがクエリを作成しないように作業を割り当てました

有効ですが、これらの警告は、経験豊富な開発者がデータベースクエリを知らないという納得のいく理由ではありません。高度に専門化されていない限り、プログラマはリレーショナルデータベースに精通している必要があります。

要約すると、ほとんどの経験豊富な開発者はデータベースクエリを知っている必要があります


1
だから、もし誰かがDatabaseを使った些細なプロジェクトをやったのなら、彼はクエリに精通しているはずですよね?
シャミムハフィズ

3
@シャミム、私はこの人がジュニアまたはエントリーレベルでない限り、クエリに中程度の経験があると期待しています。おそらく、この人は数年の経験しかなく、高度に専門化されたチームに隠れていたのでしょうか?
maple_shaft

12
@Shamim おそらくそうなる思います。彼らはまだ優秀なプログラマーかもしれません。このような質問には非常に多くの警告があるため、答えるのは非常に困難です。チームにDBプログラマーがいた可能性があります。多分、アプリケーションの重要性はビジネスロジックにあり、データベースクエリは簡単でした。プログラマーがクエリで作業しなかったように、作業を割り当てた可能性があります。など
マシューロダトゥス

4
私の開発チームは、プロジェクトの一部としてPL / SQLプログラマーを専用しています。そのため、.Netプログラマーは簡単なクエリを実行できますが、それを確認してより複雑なクエリを開発します。さらに、ORM(およびNOSQL)の普及により、なぜ非SQL開発者は複雑なクエリを知っている必要があると思いますか。
-softveda

2
@Matthew Rodatus:クエリを管理するライブラリがある場所で働いていたので、単純なSQLを理解しなくてもそこで理論的に作業することができました。私は、すべての開発者が実際にそれについて有能であると信じています。
デビッドソーンリー

23

少なくともソフトウェアエンジニアは、データベースの基本的な理解と、SQLを使用してデータを保存および取得する方法について、少なくともこれが何に使用できるのかを理解している必要があります(それにより、キー、ビューの理解も含めます) 、ストアドプロシージャとトリガー)。

すべてのソフトウェアエンジニアが専門家である必要はありません。必要な専門知識のレベルは、焦点を当てるソフトウェアの種類によって異なります。組み込みソフトウェア、ハードウェアドライバー、およびオペレーティングシステムがSQLを使用することはほとんどありませんが、アプリケーションソフトウェア(Web、デスクトップ、またはサービス/デーモンベース)は常にデータベースを使用します。


1
幸いなことに、今日では、RDBMSをまったく使用せずにアプリケーションを実行しても問題ありません。ほとんどのタスクはそれらを必要としないか、単純にリレーショナルモデルに適切にマッピングできません。使用可能な非リレーショナルストレージオプションが多数あります。
SKロジック

8
これも私の意見をまとめたものです。エキスパート?いいえ、知識ですか?はい。
ウェインモリナ

2
@ SK-logic、リレーショナルデータベースを無関係にするオプションはどのようなものだと思いますか?データウェアハウジングは、分析にはあまりにも専門的であり、トランザクションシステムでは役立ちません。そして、OODBMSのすべての問題について始めてはいけません。
maple_shaft

1
@maple_shaftには、多くの専門化されたドメイン指向のストレージソリューションがあります。RDBMSesは汎用化しようとし、その中でひどく失敗します。場合によっては、古代の階層型DBMSでさえリレーショナルよりもはるかに優れています。
SKロジック

6
すべてのデスクトップソフトウェアがデータベースを使用するわけではないため、データベースが常に発生していると言うときは注意してください。
アダムリア

18

データベースの知識が不要な専門分野(組み込みシステムなど)がいくつかあります。しかし、ほとんどのビジネスアプリケーションは何らかの種類のデータベースを使用しており、適切に使用する方法を完全に理解していない場合、修正が非常に困難なパフォーマンスの混乱を作成できます。データベースのリファクタリングは複雑で困難なプロセスになる可能性があり、多くの場所はその難しさのために構造的な問題を修正せず、穴の奥深くまで掘り下げることを選択します。データベースの知識があれば、設計はずっと簡単で、時間の経過とともにうまく機能する可能性がはるかに高くなります。

ORMは、データベースの知識を得るための代替ではありません。データベースのクエリと設計の基本を知らずにデータベースを使用する人は、アプリケーションの長期的な負荷処理能力に影響を与える、パフォーマンスの悪い、設計の悪いデータベースを持つ運命にあります。自分が何をしているかを知っている誰かの手にあるORMは問題ありません。データベースについて学習するのが面倒な人の手に渡れば、彼らは通常災害です。

データベースバックエンドを使用するプロジェクトがある場合、データベーススペシャリストは、最初のアプリケーション開発者の後、私が雇う2番目の開発者になります。通常、データベースは使い捨てではありません。データは20年後もほぼ同じ形式で存在するため、最初の段階で専門知識を持っていると役に立ちます。

データベースが1億件のレコードを持ち、実行が遅くなるまでプロジェクトを雇わないため、プロジェクトはしばしばトラブルに巻き込まれます。または、彼らは、設計の無能さではなく、ツールが悪い(正しく設計すればSQL Serverが遅くならない)ことを非難します。


4
+1は、ORMが存在しても、SQL(または使用しているdbの種類に関係する基本的な要素)を知る必要性に代わるものではないことを述べています。
-RHSeeger

4
+1して、さらに100をあげたいと思います!コーレレーション!=因果関係は知っていますが、これまで働いてきた中で最も効果的なアプリケーション開発者が標準のSELECTクエリの記述方法を完全に理解していたことは明らかです。優れた開発者にデータモデルとデータに関する「質問」を渡すことができ、その人は最終的に私の質問に「答える」クエリを作成できるはずです。
maple_shaft

1
+1、完全に同意します。「ORMを使用している」または「専用のプログラマーがいます」という説明は買わない。誰かが本当に経験を積んでいれば、ある時点でdb開発者の役割を果たしていただろう。それが経験です。
GrandmasterB

15

政治的に正しい答え:それは異なります。開発者がリレーショナルデータベースを使用したことがない場合、SQLの知識はまったく価値がありません(そして、今日のNoSQLアプリケーションの時代には、実際にそうなる可能性が高いです)。

第二に、DBAまたはフルタイムのクエリライター(タイトルが何であれ)がいる場合、理解もそれほど重要ではありません。

開発者がすべての取引をする必要があり、リレーショナルデータベースを使用するためのプロジェクトに要件がある場合(たとえば、旧式のWebアプリケーションや既存のデータベースとの接続)にのみ重要です。

私の個人的な意見:いいえ。経験豊富なソフトウェア開発者は、必要に応じて「デフォルト」ではなく、必要なときに新しいスキル(SQLなど)を習得できるはずです。柔軟性と学習と理解の能力こそが、優れた開発者と大丈夫な開発者を区別するものです。「黄金のハンマー」ルールも適用されます-SQLの知識が豊富な開発者がいる場合、この開発者が最もよく知っているツール(リレーショナルデータベース)を引き出して、すべての問題を解決しようとしますが、必ずしもそうではありません最良のソリューションになるために。もちろん、これはNoSQL支持者にも当てはまります;)。

適切な仕事に適切なツールを選択することは、経験豊富なプログラマが知っておくべきことです。


NoSQLデータベースは、リレーショナルデータベースよりも多くのデータを処理したり、高速に処理したりしません。どこで聞いたのかわかりませんが、あからさまに危険です。
アーロンノート

@Aaronaught-編集、私の未熟な仮定のヘッズアップに感謝、:)。
クトゥルフ

7

このウィキペディアのコンピュータープログラミングの概要をご覧ください。

コンピュータープログラミング(多くの場合、プログラミングまたはコーディングに短縮)は、コンピュータープログラムのソースコードの設計、作成、テスト、デバッグ/トラブルシューティング、および保守のプロセスです。このソースコードはプログラミング言語で書かれています。プログラミングの目的は、特定の望ましい動作を示すプログラムを作成することです。

データベースクエリには独自の言語があり、設計、テスト、デバッグ、管理が可能です。データベースクエリの目的は、必要な情報を必要な方法で取得できるようにすることです。

だから、間違いなくプログラミングだと思う。


7

エンタープライズおよびビジネスアプリケーション(編集:特にRDBMSを使用するプロジェクト)のバックグラウンドを持つ優れたソフトウェアエンジニアは、標準形式でリレーショナルデータベースクエリを記述する専門知識を持っている必要があります。さらに、複雑なスキーマを理解し、少なくとも中程度の複雑さのスキーマ設計を提案できる必要があります。

非常に高度または複雑なスキーマ設計は、データモデラーまたは機能設計者の領域でなければなりません。

これは、データベースプログラマーにも場所がないという意味ではありません。単一のデータベースベンダー(Oracle、MySQL、SQLServerなど)のユニークなツールと製品に焦点を当てた複雑なストアドプロシージャ、複雑で効率的なクエリ、およびデータベース層のソフトウェア設計とアーキテクチャは、可能な限りプロフェッショナルソフトウェアに残す必要があります。これらの非常に専門的で複雑なオファーリングの経験があるエンジニア。

しかし、私の意見では、ビジネスおよびエンタープライズシステムの大部分は、データモデラーや専門的なデータベースプログラマーの必要性を正当化するものではありませんが、これらの人々がテーブルに持ち込んだ知識と専門知識から大きな恩恵を受ける前に、そのようなプロジェクトに取り組んできました。


2
-1:「良い」ソフトウェアエンジニアがリレーショナルデータベースクエリの専門家であるべきであることに強く反対します。
ジョンサンダース

3
(組込システムなどとは対照的に)優れたエンタープライズまたはビジネスアプリケーションソフトウェアエンジニアと言い、この人がSTANDARDリレーショナルデータベースクエリの専門家であると言ったら(派手なパンツベンダーなしで)分析クエリなどの詳細)SQL SELECTステートメント、すべてのタイプの結合、ユニオン、インターセクトとマージ、インラインビュー、条件、順序付け、および結果セットのグループ化を完全に理解することは、上記で指定したラベルを持つソフトウェアエンジニアによって十分に理解され、十分に実証される必要があります。
maple_shaft

4
えー 私は大規模なソフトウェア会社で働いており、RDBMSには一切対応していません。デスクトップソフトウェアを開発する私の最後の仕事でも、SQLは必要ありませんでした。エンタープライズアプリケーションやビジネスアプリケーションをどのように定義するのかわかりませんが、物事に対するあなたの見解は少し狭いように思えます。
アダムリア

2
私が言ったことを支持します。理論的には、アプリケーションが適切に階層化およびコンポーネント化されている場合、プロとしての経験全体で私のチームは必要ありません。RDBMSの設計と開発に専任のチームがあったとしても、SQLの専門家でなかったなら、私はROW死します。おそらく私は昔ながらですか、それとも私のキャリアでひどい運がありますか?
maple_shaft

3
@maple_shaftええ、私が取り組んできたアプリケーションが十分にコンポーネント化されていたわけではありません。それは、彼らがRDBMSを使用しなかったということです、期間。異なる分野だと思います。ポイントは、すべてのビジネス/エンタープライズ開発者がSQLに精通している必要があるとは言えないということです。それは単に真実ではありません。あなたがそれを使用する場合、それが得意です。他の言語やテクノロジーのように、必要になるまで気にしなくても大丈夫です。
アダムリア

6

他の人はすでにデータベースクエリに関するあなたの質問に答えています。

データベース設計は、特定のタイプの設計です。学ぶことはそれほど難しくありませんが、典型的なデータベース設計者はデータベースを設計するそれほど多くの機会を得ることはありません。

現在作業中の場所は、1970年と同じデータベース設計です。データベースをIDMSからDB2に移動しましたが、同じネットワークデータベース設計です。ここで働いてきた9年間で、5つの新しいDB2テーブルを作成する機会がありました。

専任のデータベースデザイナーがいる職場はほとんどないと思います。したがって、データベース設計は上級アナリストのレパートリーの一部と見なされると結論付けます。


5

私は非常に多くの人が、すべての開発がデータベースとそのSQLデータベースを中心に展開していると考えていることを率直に驚いています。

他の人は、データベースで(間接的に)作業しているときでも、ジョブでSQLの本質を回避できる多くの方法について言及していますが、101の電気製品のファームウェアを作成するすべての開発者はどうですか持っている?リアルタイム監視を専門とする人はどうですか?

今日の開発者の大部分は、さまざまな程度のSQLスキルを持っていることをお勧めしますが、それは彼らの能力のバロメーターではありません。


5

ソフトウェアにおけるデータベースの重要性を過大評価していると思います。

アプリケーションの多くのクラスはデータベース中心ではありません。

ワードプロセッサと画像エディタにDBMSが必要になりましたか?音声認識やコンピュータービジョンシステムについては、これらには多くのデータベースクエリが含まれていますか?

また、リニアビデオエディターやビデオゲームの物理エンジンはどうですか?


5

ジェネラリストの開発者は、少なくともデータベーステクノロジー(リレーショナルまたはその他)を認識し、それらを使用することの長所と短所について議論できることを期待しています。そうでなければ、彼らが行う方法を知っているのは、データをフラットファイルに詰め込むことだけだと思います。


4

クエリの作成はプログラマにとって必須の要件ではないと思います。そうは言っても、クエリを作成してデータベースを設計できるプログラマは組織にとってより価値があると思います。

ただし、このプログラマーが「select * from tblxxxx」タイプのクエリのみを記述できる場合、このプログラマーを専門家とは見なしません。同様に、このプログラマーによって設計されたデータベースが2つのテーブルではなく1対多の関係を1つのテーブルに配置する場合、このプログラマーをエキスパートとは見なしません。

これをIT以外の人に説明する方法を次に示します。ITプロフェッショナルは、大工、電気技師、配管工が尊敬される分野を専門とするのと同様に、特定の分野を専門としています。彼らはいくつかのスキルをオーバーラップする傾向がありますが、すべての分野の専門家ではありません。電気技師は簡単に大工仕事を自信を持って行うことができますが、複雑な構造に取り組むことはうまくいきません。

同様に、プログラマーは、単純なクエリやデータベースの設計を記述または操作する方法を知っている必要がありますが、複雑なデータ構造を設計することは期待されていません。


3

私たちの部署を見てみると、それは次のとおりです。

  • 私たちのデスクトップ/ウェブ/サーバーの開発者。少なくとも専門分野に応じて、基本的なものから高度なものまでの記述を書く必要があります。最適化のために、いくつかの専門のDB管理者がいます。
  • 私たちの組込みプログラマ。かなりの数が「select * from mytable」を一度も過ぎたことはありません。ただし、この数か月でsqlliteがプロジェクトに導入されたことで、状況も変わりました。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.