Q&A
「フレームワーク」という言葉の指す範囲は非常に広いんで、タイトル文が意味不明。
（DB関係ない「フレームワーク」なんて世の中ゴマンとある）
単語の意味をちゃんと調べて理解しよう。
質問
現在、バックエンドエンジニアへの転職活動中でポートフォリオを作成しております！
先日現場のエンジニアの方から「SQL文を使えないのはダメだ」と言われてしまったのですが、PFレベルのアプリケーション開発ではO/Rマッパーを使用すればSQL文を深くは理解しないままそれなりのDB操作が出来てしまうためあまりピンときませんでした。(一応生成されるSQL文は理解できます！)
そこで現場でORMを使用している方に質問なのですが、どのような場面でSQL文を理解、使用できないと困るのが教えていただきたく質問させていただきました。
私の予想では
・FW内ではなく直接DBを触る機会が頻繁に発生するため
・実際のアプリケーションではORMの簡単なメソッド では絞り込むことができない複雑なDB処理がしばしば発生するため
なのかな、と考えております。
宜しくお願いいたします。
回答6件
0
ベストアンサー
O/Rマッパーを使う上でもSQLの原理は知っておいたほうがよいと思います。たとえば、排他制御、一意制約とか大丈夫ですか?
以下のように、現実の「事故」も発生しています。
「雇用調整助成金」は、売り上げが減少しても企業が従業員を解雇せずに雇用を維持し、休業手当を支払った場合に国が手当ての一部を助成する制度で、休業を余儀なくされた企業のニーズの高まりなどを受け、厚生労働省は20日から手続きを簡素化するためオンラインでの申請の受け付けを始めました。
しかし、申請するための専用の画面にアクセスすると、ほかの申請者の名前やメールアドレス、それに電話番号などが見られる状態になっていたということで、一般の申請者からの問い合わせを受け、現在、受け付けを中止しています。
厚生労働省によりますと、同じタイミングでシステムに登録すると本来、個別に割りふられるはずのＩＤが同じになり、個人情報が見られる状態になっていたということです。
「雇用調整助成金」オンライン申請 不具合 復旧めど立たず | NHKニュースより引用
こういう問題は、SQLの基礎がわかっていれば起こさないはずの問題ですが、「データベースの操作さえできれば良い」と考えている人が作ると起こしがちではないかと思います。
これを題材にして動画を作りましたので、参考にしてください。
会員登録が混雑するとIDが重複してしまうサイトを作ってみた - YouTube
また、ウェブアプリケーションの開発だけでなくバッチ処理のスクリプトを書く場合や、保守業務などでSQL文を書くことは、どの現場でもあるように思います。
転職活動中とのことですが、面接官から「SQL文の読み書きはできますか?」と質問されて、「O/RマッパーがあればSQL文がわからなくても大丈夫なのでSQLの勉強はしていません」と回答したら、面接官の心証はよくない気がします。
投稿2021/05/06 05:34
総合スコア11705
ありがとうございます。
排他制御ついては存じ上げておらず少し調べてみたのですが、上記の例ですと同じデータにアクセスした際の排他制御がなされていないため同時にデータ登録が行われてしまい、また一意制約が設定されていなかったため同じidが設定されて起こった事故と考えられますね。
仰るとおりSQLを意識せず、ORMのみに頼っている場合それらの制御を意識する場面がないので危険なプログラムを書くことにつながりかねませんね。非常に参考になりました！
添付していただいた動画も拝見します。誠にありがとうございます！
0
SQLの知識は必須だけどSQLは書かない。
プロジェクトごとに方針は違うんだから一般的な答えなんかない。
投稿2021/05/06 05:02
退会済みユーザー
総合スコア0
0
Laravel などのフレームワークを採用しておきながら、ORM を毛嫌いして、DB::raw() の使用を推奨したり、強制する一派は少なからず生息しています。
普通に ORM 使う方が、フレームワークの提供する機能を犠牲にしなくて済むのですけどね。
フレームワークを利用しているのであれば、
- 基本的には ORM で書く。
- パフォーマンスに著しく悪い影響がある場合に限り、生SQLで書く
というのが現実的でしょう。
「パフォーマンスに著しく悪い影響がある場合」となると構造も複雑だったり、リレーションも複雑になりがちなので、そういった場面では、SQLの高度な知識は必要となります。
古くからプログラミングやっている人の中には、「生SQL原理主義者」がいて、自分の観測範囲では、フレームワークの知識が浅すぎて、「生SQLでないとパフォーマンスが・・・」などという人がそのタイプ。
フレームワークのことをしっかりわかっていて、SQLもちゃんと知識あった方がいいよという人もいる。
確かに、デバッグの時などは、SQLわかっている方が強い場面は多いよいうに思います。
投稿2021/05/06 05:01
総合スコア3923
ご回答ありがとうございます！
やはり頻度としてはORMを使用する場面が多いものの、デバックや複雑な操作の際に理解が必要ということですね！
そうですね。
やっぱり、SQL知っている人と、知らない人では、その人の書くプログラムの品質にも影響するので、SQL知らない人のプログラムの品質は悪い傾向にありますね。
とくに、リレーション周り。トランザクション、排他制御...
ありがとうございます。
他の方も書かれていたのですが、SQLの知識がかけているため排他制御や一意制約での致命的なミスを犯すことにつながりそうなので、できる範囲で理解しアピールにつなげられるよう学びたいと思います！
0
ポートフォリオは結局「自分は現在何ができる、こういう趣向を持っている」というアピールのために作るものですし、採用する方はそれらを見てどういう現場に投入するか考えるものです。
現場がどのようになっているかを考えたところで、現在の実力以上のところに配置されることはないのですから、「何がどの程度できる」がきちんと伝えられるような資料を準備するのが先決ではないでしょうか。
何事も「できるに越したことはない」のはどんな現場や業界でも当然のことですが、嘘ついたところですぐ（もしかしたら書類選考レベルで）バレるので。
ここで「深く理解したほうがいい」とアドバイスを真に受けて「じゃあ今から」って間に合うわけがありませんし。
もしSQLもしくはデータベースの理解度を伝えたいのでしたらアプリケーションそのものよりも、ER図とか正規化されたデータベース設計とかそこからどのようにパフォーマンスを出すように工夫したとか、そういう資料があった方がいいでしょうしね。
「バックエンドエンジニア」とひとえに言ってもやることできることは非常に広いので、自身が何を主としてアピールしたいかでしょう。
投稿2021/05/06 05:39
総合スコア80875
誠にありがとうございます！
おっしゃる通り、付け焼き刃で知識を入れ過ぎずに現在自分が出来る範囲を詳しく説明できるようになり、また携わりたい業務の解像を高めたいと思います。
>解像を
・・・えーっと「理解」「解析」でしょうかね。
あとは「今後の展望、趣向」まで伝えられると、期待値含めて配属を考えてくれるかもしれません。
申し訳ないです…解像度と書くつもりでした…！
重ねてありがとうございます。現場の人の情報などをもとに入社後の展望も伝えられるようになりたいと思います。
「業務の解像度」で意味通じるのでしょうか（私は「ん？？？」となります）
「確度」「粒度」ならまだ分かります。
あと「現場の情報」って秘密保持関連でまともに外に出ることはないので、転職なら転職エージェントから情報得るべきかと。
そうですね、粒度または業務に関する知識の解像度、って書いた方が宜しかったかもしれません。
転職エージェント活用してみます。
詳細にわたりお答えいただきありがとうございました！
画素とかピクセル密度に対して「解像度」を使うことはあっても
知識とかその方面で使うことはないかと思います。
「言葉の解像度」などと使われている場面がある気がしますが、いわゆる若者言葉なのかもしれません！
こういった場所では使用を控えますね！勉強になります！
なるほど。「言葉の解像度」ならまだなんとか理解できなくもないです。
より一般的で適切な表現があるなら、わざわざ使用する必要もないかと思います。
いずれにしても「業務の解像」とだけ出てくると意味不明なのは確かですね。
0
どのような場面でSQL文を理解、使用できないと困るのが教えていただきたく質問させていただきました。
クエリのスピードチューニングを行う上では、SQL文からEXPLAINしてデータベースサーバの挙動を探る、ということが欠かせないです（最終的にクエリビルダーを使った形で充分な性能が出るようにできることが大半です）。
投稿2021/05/06 05:17
総合スコア145930
アプリケーションロジック以外のデバックなどで使用するのですね！
ポートフォリオ作成時には全く意識できていなかったです。
ありがとうございます！
0
その現場でフレームワーク使ってない･･･なんてことは無いんすよね。
だとしたらどういう事やってるか読めれば正直良いと思うけどなぁ･･･。
まぁ物によって生のSQL書くこともあるんで書けることに越した事は無いっすけど。
まぁでも個人的見解なので参考程度に留めて下さい。
投稿2021/05/06 05:10
総合スコア1282
あなたの回答
tips
プレビュー
