  |
はてなキーワード: SQLとは
やっぱりそういうこと？
このままSIerで耐えててもWeb系で役立つスキルなんて何一つ身につかないということはわかってる。
でも、ここで今すぐブラックなWeb系でもいいから飛び込んでスキルを磨くのと、しばらくSIerで耐えながら余暇でスキルを磨いて悪くないところに転職するのと、どちらがいいかがわからねえ。
今のスキルはJavaがそこそこ（ユーザー系SIerの同期の中では）できるだけ。SQLは簡単なサブクエリぐらいしか書けない。データベースの設計もあまり経験がない。インフラ知識はゼロ。情報処理で応用情報技術者とネットワークスペシャリストをマグレで取った程度。
残酷だが「職業訓練でプログラミング」という人たちはこの業界はあきらめた方があなたのためにとって良い。
そのような人の上司になったことが何度もあるが成功した人を見たことがない。
とはいうものの、私も35歳から異業種転職にてアプリ屋になったが、転職直前の段階でC/C++/Pascal(Delphi)/html/js/SQL が書けた。
10代前半から8bitCPU(特に名を伏せる)のマシン語(ハンドアセンブル、つまり16進数直書き)でプログラムした経験がある。(もちろんBASICもある)
8bit時代ならメモリー増設の設計・実装(ハードウエア)ができた。
一応そのような状況ではあってもプロに知り合いもなく心配だったので、
(当時)第二種情報処理技術者試験に3週間の勉強(1.0/日程度)で
一発合格しなければ転職しないというような目標もたててクリアした。
技術的には 0 スタートではかったからこそ転職にも成功できたと思っている。
おっさんで技術的知識・経験ほぼ 0 スタートはきついでしょ。
ユニークというと日本では「おもしろい」とかいう意味で捉えられますが、
本来は「一意性がある」、簡単に言うと「他にない唯一のもの」という意味です。
これを設定しておくと、「同じ値を2つ以上登録できなく」なります。
投票データは「投票コード」と「立候補メンバーのID」が入るでしょう。
こんな簡単な設定をシステム開発会社がしてないとはとても思えず、
重複投票は弾かれるはずです。
一万歩譲ってこの設定をしてなかったとしても、
よって重複投票はまずありえないです。
よって、重複投票はありえません。
おぎゆかおめでとう！！！
何度もオーディションに落ちながらも諦めなかった苦労人に
光が当たるととても嬉しい。よかったね！
このSQLは何をするために何をしているのか、いつどのような目的で使うことを想定して書いたのか
を書く。主に自分のために。
でも、SQLって運用段階に入っていくと、少しづつ更新されていくじゃん。そうするとコメントと合わなくなっていくんだよね…それが辛い。
SQLは意識して書かないと死ぬほど読みにくくなるのが気に入らない。
前の職場には何もかも全部大文字で表記し、ろくに改行も入れないバカが居て死ぬほどつらかった。あろうことか、読みづらいクエリを書ける自分にプライドを持ってるっぽかった。ああいう奴とは二度と仕事をしたくないよ。
SELECT COL0,COL1,COL2 FROM TABLE0 WHERE COL0=1000 AND COL2 IN (100,102)
これを少しでも読みやすくするために予約語を大文字、カラム名やテーブル名を小文字で表記している (カラム名・テーブル名が大文字で決め打ちされているなら、予約語を小文字で統一している)。
SELECT col0,col1,col2 FROM table0 WHERE col0=1000 AND col2 IN (100,102)
しかしこの方法も万全ではなくて、例えば複数のテーブルが関連するクエリが
SELECT t0.col0, t0.col1, t0.col2, t1.col0 FROM table0 t0 LEFT OUTER JOIN table1 t1 ON t0.col3=t1.col3 WHERE t0.col0=1000 AND t0.col2 IN (100,102)
みたくなってしまう (テーブル名のtable0、仮名t0、カラム名col0が全部小文字になっているため、なかなか読みづらい)。
皆さん、どうやって工夫されてますか？
構文によって書き方が違うのがわかりにくい。
SELECTはまだいい。問題はINSERTとUPDATEである。
INSERTはVALUESで書くくせに、UPDATEになるとSETで=でつなげているのモヤモヤする。
さらに()が必要な構文だったり必要ではないものであったり統一感がないのが混乱する。
INTOで文章らしさを出しているのかしらないが、どちらにしろ文章にならないので中途半端なのでいらないのではないだろうか。
ちょっとした検索したい場合はいいかもしれないが、プログラムの一部としての長ったらしいSQLは可読性も悪ければ保守性も悪いで誰も得しない。
さらに解決される順番が未だによくわからない。特にGROUP BYを使う場合にどういったタイミングでされるのか非常にわかりにくい。
サブクエリを無駄に重ねたり、ON DUPLICATED KEY UPDATEをわざわざ書いたりとなぜ１文で完結させようとするのだろうか。
どっちみちトランザクションで複数文になるのならば、最初から複数文となることを前提した仕様としてもいいのではないか。
（そもそもコードから呼ぶ場合はフレームワーク周りでなんとかしろという話ではありますが）
他にもストアドプロシージャやSQL高速化の問題もあるとは思うが、自分自身が未熟者でそこまで語れないので書けない。
プログラミング言語については様々な文句が噴出するにもかかわらずSQLについて文句が出ないのはどういう了見なのだろうか。
反対にNoSQLでRDBMSのようなことを始める本末転倒な人たちも見かけるがそれぞれ適材適所な使い方をするべき。
体系的に学んでいれば今よりもっとすっきりと理解できるものかもしれないが、嫌悪感を抱いてしまった以上は学ぶことなくずっと憎み続けていくことになるのだろう。
そういうわけでやはり僕はSQLが好きになれない。
みなさん、返事ありがとうございます。初めてで書き方が悪く、答えようがなかったですね。皆さんの質問に答える形で補足させて頂きます。
名古屋から1時間ちょっとの人口8万人の都市。全国の普通のチェーン店がある、普通の田舎。テレビは７ＣＨ映ります。自然とうまいバランスで住みやすい都市だと思う。
年齢は45歳くらいまでがいい。もちろん若くてもいいです。
【具体的な業務】
・各種開発作業
１）サーバー側で稼動してる、パワコンデータ受信プログラム（PHP / sh）
２）端末側で稼動している、データ取得送信プログラム（C++ / PHP / ash）
３）Web管理画面HTML、およびCGIプログラム（HTML / CSS / PHP）
MySQLのクライアントアプリより既存データの修正や削除、データ入れ替え等を行います。
大量件数の場合は、SQLクエリを作成し一括で操作を行います。
などです。まあ、実際は今のサービスは開発よりも、運用保守重視。主にサーバー上のプログラムやデータの整理が主です。
上記よりも、使い始めた人からちょくちょく問い合わせが来るのでその対応がメインになると思います。
仰るとおり、美しいプログラムでほぼソフトウエア的な保守は必要ないです。
上記まで（ほぼ問い合わせ）が一日1時間くらい。
だから求めるスキルは新サービスを何とか形にしようとする意識と情熱、グーグル先生に聞いて自分で問題を解決しようという気があればいいです。
もちろん、あるに越したことはないですよ。その分しっかりお支払いします。
具体的には 下請け仕事はしない。自分たちが面白いと思うことしかやらない。（開発しない）
エンジニアの人にはアイデアは僕が出すから形にして欲しい。それか一緒にアイデア出しあって、面白いサービスをリリースしよう。マネタイズは経営者（僕）が考えるから。
上記スキルがあって
年収は400万～
いざとなったら出社は週に2-3回でもいい。
都会から弊社の近くに引っ越してくれるなら、アパートくらい用意します。
釣りやスキーやロードバイク、アウトドアが好きなら、申し分ない環境だと思います。
はてなはじめてで、ここでいきなり全部書くのはちょっとと思って、ふわっとした最初で、様子見でごねんなさい。
さて、これくらい書けばちょっとはおっ！って思ってくれるのであろうか？
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など（特定されそうだからぼかすけど。）
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
（そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。）
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。（あとで聞いた話、外部コンサルで外れを引いたらしい）
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし（有難迷惑だった可能性は否定できないが）、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社（厳密にはその親会社に）に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。（ITインフラ部署の無い会社はさすがに無いはずだ）
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
（ここで簡単のために旧弊社を（旧）A社、買収した側の競合他社を（旧）B社と呼ぶことにする。）
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ？」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。（つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい）
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）
そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。
29の時にプログラムを始めて今年で3年目。
彼の方がひとつ上だけどまあまあ同い年みたいなかんじ。
最初は10年以上やってるんだからできる人なんだろうと思って接してたけど
この1か月一緒に仕事した結果すべてが適当でレベルが低いというのがわかった。
でも彼はそうだと思ってないようで何かと上から教えたがる。
入ったばっかだし試用期間だから素直に聞いてるふりをしてる。
それでも適当なことばかり言ってくるからいい加減限界が近づいてる。
（リレーション使うとSQLが重くなるからなるべく使わないようになど）
立場は後輩なわけで実際指摘した方がいいのはわかるけど
それでも先輩の仕事にケチつけるわけにもいかないじゃないですか。
わからないふりして質問して遠回しに指摘しても全く気付かないし
これはおれのやり方が悪いのは重々承知だがそれでも
彼よりおれの方がまともに仕事してるっていうのは1か月仕事したらわかると思うんだよ。
MicrosoftはExcelと親和性の高い、Power BIというビッグデータ分析ツールを無料で出しています。
https://powerbi.microsoft.com/ja-jp/
あなたは、これかこれに類する分析ツールを使って、自社データの分析ができるようお膳立てをし、できるならいくつかの分析サンプルとともに部長さんに提案すればよかったと思います。
この手のツールは、データ分析やSQLの専門家じゃなくても使えるようになってるので、部長さんも十分使いこなせる可能性がある。
知らないことはできないわけで、できるようにお膳立てするほうが、あなたにとっても部長さんにとっても会社にとっても利益になるのではないかと思います。
今からでも遅くありませんよ。
増田の用途だとAccess使っても結局フロントエンドでExcel使わんといかんような気がするので、おすすめしない。
ソートに関してはマクロとかで改良できると思うが、重くなる問題はどうしようもなかろう。
ハードウェアのアップグレードで対応するという姑息な手段もあるが、Excelファイルは肥大化していくだろうから、問題を先送りにするだけという気もする。
きちんとしたデータベース（SQL）の知識があれば解決できるのだと思うが、かなり敷居が高い。
似たようなことでずい分昔に悩んだことがあるので、思ったことだけ書いた。参考にはならんな。
ECサイトの運営を任されて4年。これまで蓄積された販売データは50万件以上に上る。
もと営業マンの上司（部長）がこの販売データに目をつけ、分析したいと言い出した。
どういったデータが欲しいのか要件定義をしてもらえればいくらでもデータ提供するのだが、この上司は「自分で分析をしたい」という欲求が非常に強い。
そして具体的な分析イメージが持てていないので、要件定義が全く出来ない。
それじゃ、って事でECサイト管理者権限を与え、管理ソフト上での閲覧もcsv吐き出しの方法も教えたのに、今度はそれが使いこなせない。
毎日ギャーギャー騒いだあげく、ついには「全部のデータをExcelで見れるようにしろ！」と言い出した。
「ビックデータ解析に一番有効なツールはExcelです。」だそうだ。
部長の後ろの本棚に最近そういう本が並んでいるのは知ってた。知ってたけど関わりたくなかったので無視していた。
それがついに正式な業務命令として振ってきてしまった。もう避けることは出来ない。
祝日出勤のイライラもMAXだったので、昼休み明けに1.5GBのcsvデータ作って部長のPCに放り込んであげた。
部長は大層喜んだ。「やっと分析に着手出来るな！」って他部署に聞こえるくらい大きな声で宣言してた。
で、さっきから“ファイルを開こうとする毎に画面真っ白になる”っていうのを延々繰り返して「なんだよこれー！！」ってキレててウケる。
もし、勉強しなかったらちょっと単価の高い別のメンバーにやってもらう方が安上がりなので、業務内で勉強させるつもりは無い。
はNGで、
・SQLできるメンバーにこの業務やってもらおうと思っているよ。
は大丈夫だろうけど、
・もしSQL勉強してきたら、次この業務やってもらうよ。勉強しなくても別のメンバーに頼むから大丈夫だよ。
・もしSQL勉強してきたら、次この業務やってもらうよ。勉強しなくても別のメンバーに頼むから大丈夫だよ。ただ、君の評価に与える影響は大きいよ。
どこまでだったら、良いかな？
運用なので実装や開発ということもなく、何かシステムに修正があればテスト、というような感じ。
先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、
やっぱり運用プロジェクトというせいかモチベーションが上がらない。
最近は毎朝起きるのも遅い。
以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり
会社に入ったばかりでやることはどれも新鮮。
少し難しい仕事も任されるようになってきてモチベーションもあったと思う。
それが今では不思議と朝起きたくないのだ。
起きるのがつらいというか億劫。
別に疲れが溜まっているわけではない。
目覚めは悪いどころかいつも目はぱっちりしている。
でも起きれない。ぎりぎりまで布団の中。
そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。
この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。
今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。
会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。
今では職場でも私生活でもいきいきしている。うらやましい限りだ。
自分はフリーランスにはなろうとは思わないけども、少なくとも今のプロジェクトは半年が限度かなーとは思ってる。
それに自分の市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。
そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。
運用プロジェクトの残念なところは、仕事の大半が顧客対応のコミュニケーションコストでつぶれること。
特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。
障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..
なんてことをつらつら書かなければいけなかったり。
なにより障害が発生したらものによっては休日にも出勤しなければならないこと。
まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。
体力には自身があるけども精神的にはわりときます。人によるのかな？
つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。
運用プロジェクトでは顧客対応が必須だ。なので顧客との話し合いは上手くなる。
例えばフレームワークの脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。
ハードウェア、ミドルウェアに障害が起きればそれに対する知識を駆使して対応を行う必要があるし、
ドメインが変わった、IPアドレスが変わった、となればシステムの運用や保守作業で影響がないか調査する必要がある。
他にも必要な知識として、プログラミング言語とSQLはそこそこかけて、DBクライアントやLinuxの操作、その他ミドルウェアの知識も必要になる。
なので現時点では自分のスキルはそこそこ伸びてはいるのかなーとは感じている。
理想は運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。
