  |
はてなキーワード: DBMSとは
[自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜JoanOfArc](https://note.com/joan_of_arc/n/ned510ca913c7)
1. 今はなき鉄鋼メーカー、研究所で新規シミュレーションコード立ち上げ
メンターが米国自動車メーカーへ転職して途方にくれた。電磁気学の教科書を読み漁って掲載されているサンプルコードを理解して、コード手打ちして3ヶ月で動く様にした。社内で誰も見たことが無い結果に驚かれた。
2. 鉄鋼メーカーの人員削減が若手にも迫ってきたので、電子部品メーカーへ転職。コードは書かず開発現場で製品試作品の制作をモクモクと行う。
3. 色々あってプログラマー派遣会社へ転職。ドコモ向けのアプリのテストデータを作成するだけの仕事をアサインされた。楽勝の仕事だったが、拘束時間が長く半年で10kg太る。
4. 派遣で今はなきシャープ常駐でデジカメファームウェアの開発現場に放り込まれる。C言語の未知のコードとLSIの仕様書に戸惑ったが、親切な若手社員に助けてもらって独り立ち出来た。2年程やったが、雇い止めに合った。
VC++製の画像処理アプリもメンテした。VBの画像処理アプリも自作した。
5. 現NTT、当時住友銀行子会社で常駐で電磁界シミュレーションアプリの新機能開発を担当。分散処理による計算時間短縮を狙う部分を担当。分散処理はMPI(現OpenMPI)を使用。まずはパソコン2台で分散処理を行うもNIC(LAN Card)がボトルネックで計算は出来るが1台で計算するよりパフォーマンスが出なかった。職場にジョインしたあとは、しばらくは訳がわからず、戸惑った。通勤時間が長く体が消耗した。
派遣プログラマーは嫌で正社員で働きたかったので、プログラマーにこだわらず職場を探した。知財の職に採用されたので、常駐先と派遣会社に退職を願いでると引き止められて困った。退職を強行して転職できた。離職票の入手に苦労した。暑い夏だった。
6. 中小製造メーカーの知財の職場では要領よく仕事をこなしていると時間があまる。余った時間で社内WEBサイトを作ったりした。使ったのはASP(ASP.NETの前身、VB.NETでコーディング)。フレームワークに従ってコードを埋めるとそれなりに動いた。DBMSはAccessを使った。要するにmdbファイルにデータを保存した。更新処理は管理者のみ、データの閲覧が主な機能であるWEBサイトだった。
7. 知財の仕事は楽勝なのだが、やはり開発の仕事に未練が出てきた。iOSアプリの開発もやってみたくなった。10年以上知財の仕事を行ったが思い切って無職へ転向した。親父も無くなり、遺産の整理もサラリーマンを行いながら難しかったのだ。(つづく)
というかトランザクションを見逃してた、トランザクション上手くやりたいならまともなDBMS入れないと無理
誰も使ってないWindows PCとか転がっていればSQLServer Express（無料）とか入れてやる？通信の面倒くささでいえばSQLiteと一緒だろうけどエンドユーザー側がドライバとかインストールする必要はないはず（ODBCデータソースの設定は必要、めんどくさい……）
どうせODBC使うならドライバインストールくらいって思ってついでに増田がLinux慣れしてるなら鯖立ててポスグレでもMySQLでも何でも使えばいいと思うけど
SQLServerのOLEDB接続、廃止されたもんだと思ってたら復活していたらしい エンドユーザー側の設定不要だと思うからこれが一番楽かも？
追記2
たとえばC#など.NET系のリファレンスはMSDNで読むことができる。
RubyだってHaskellだってScalaだって、公式サイトにガイドぐらい置いてある。
Oracle、DB2、MySQL、PostgreSQL、SQLite、AccessなどSQLが実装されたDBMSは様々にあるが、どれを取っても仕様が違う。
皆が標準SQLに従っていてその上で適当に増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。
根幹的に必要な機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。
これと上記１とのせいで、何かググった時に特定のDBMSでしか解決法にならないものが大量に出てくる。
最近のプログラミング言語は大抵、雑に書いたってコンパイラが適当に最適化してくれる。
同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。
SQLもオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。
そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、
より速い中間言語が生成されるようSQLをチューニングし直さなければならない。
これでは何をやっているのかわからない。
有名なサイトでは、初心者が必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、
なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。
しかもその文法、ググってもろくな解説が無かったり、特定のDBMSに依存してたりと使えないオチ。
上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。
エディタが単なるメモ帳でしかないようなDBMSも多いから、インデントの文字数さえ個々人に任される。
インデントは2文字か4文字か。SELECTで改行するかしないか。カンマは列の後ろか、前か。
いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。
つまり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。
何かの解決法をググるたびに違うスタイルだからどう書いていいのかわからない。
結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。
ジャンルがわからんので何ともいえんけど、大卒の新人とか見てると、自分の仕事こなせるようになるまで3年はかかるね。
だから1ヶ月強でそのレベルまで達しているなら、それだけでスゴいと思うけどｗ
「そっち側」というのが (広義の) Webサービス構築をひと通り自分だけでこなせるぐらいのスキルだとすると、こんな感じか？
ググったりパクったりしながらでもいいので、とにかく経験することかな？
結局一定レベルを超えると、どれもパターン化できちゃうことに気づくと思う。
http://anond.hatelabo.jp/20080504230316
たぶん「ギーク」と「エンジニア」をごっちゃにしてるのが混乱の原因ではないですし、そもそも混乱はしてません。コーディングがうまいのも、画像認識の仕組みを考えるのも、僕にとってはあまり違いがあるようには思えません。コーディングについて考えていけば、実際に手を出すかどうか（出せるかどうか）別にして、htmlやcssという言語やブラウザに対してあーしたい、こーしたい欲がでてきます。
いや、大分違うと思います。画像認識とかあるいはシミュレーションとか、そういう分野はコンピュータ・サイエンス以外の分野がメインの従来型のエンジニアであって、画面上でやる作業の比重が相対的に低いです。それに、コーディングの場合は「質を問わなければ」解けるとわかっている問題を解くのが作業であるのに対し、画像認識のような分野は解けるかどうかやってみないとわからない問題を解くわけです。これは似て非なる作業です。要求されるバックグラウンドも違います。コーダーの意味でのプログラマーは学歴不問でセンス勝負でしょうが、画像認識のような分野の技術者は大学院レベルの知識と経験が前提になります。
つまり、「出せるかどうか」が問題になるわけです。従来型のエンジニアは「ギーク」のような見事なコードは書けないだろうけれど、それは大した問題ではなく、学識の集積をライブラリやモジュールの形で提供できればよい。コーディング職人は小難しい知識は必要がないから、従来型のエンジニアが書けないような質の高いコードを書けばよい。
そういう風に、向いている方向が大分違う。それを私は「職人芸」と「技術」の違いだと書いたわけです。
勿論それはそう。ただ、そんなことを言えば小説家や画家だってしょせんは紙の上の世界で勝負してます。
そこに意味を見出せるかどうか、です。
狭い世界で芸の奥義を極めたいならギークがよいでしょう。ですが、コンピュータの中に閉じこめられるのが嫌なら、従来型のエンジニアになる手もあります。こちらに行くとギークと違い、才能やセンスよりも知識と努力で道を切り開いていくことになります。
電気・電子工学を学べばコンピュータがブラックボックスではなく電気機器の塊になる。情報工学を学べばOSやDBMSを使うのではなく作る立場になれる。制御工学・信号処理を学べばコンピュータに目鼻を付けることもできる。経営工学を学べばシステムの全体を設計することもできる。そういう道の選び方もあります。
そうした道に方針転換をするのも悪くないのでは。今まで学ばれた経験がなければ社会人大学院に行くのもよい。その際、今まで培ったギーク流のコーディング能力があれば、同等の知識を持った純粋培養のエンジニアよりも一歩優位に立てるはずです。
どちらがいいのか。一度考えてみてはいかがでしょう。
