  |
はてなキーワード: SQLとは
この記事を読んで思い出した、少し前の話
ただ思い出したこと書きなぐるだけなので、内情がどうとかそういうのは知らない
http://tnaoto.hatenablog.com/entry/2019/04/09/070227
その頃俺は富士通やパナソニックの下請けで現場に入る、所謂人売りIT企業（SESって言うの？）にいて
どの現場も多かれ少なかれ酷い事はあったんだけど、富士通の現場は本当に最低だった
製造工程から参加してたんだけど、俺の主な仕事はOracleプロシージャで作られたシステム間連携処理を
富士通の用意しためちゃめちゃ使いにくいExcelフォーマットで文字にして起こすこと
円柱の図で表したテーブルを矢印と線を使って繋げて取得元テーブルを表現
取得項目は図の右に表を書いて、条件と結合は全てSQLをそのままコピーして「項目Aと項目Bを結合」って日本語に書き直してた
それを200本くらい？作る仕事。
それはまぁ酷いとは言え人売りIT企業としてはオーソドックスな仕事じゃないですか？
でもプロシージャは毎日書き変わっていて、自分がどれを設計書に起こせば良いか分からなくてさ
でもあいつら朝来ないんだよ、早くて11時くらい、遅いと18時とかかな。連絡無しに来ない日もあったな
そのくせ会議大好きで、日次ミーティングは絶対にやらなきゃならないってルールなんだよ
もう嫌で嫌でしょうがなかったなー
結局一年半くらいやったのかな
富士通やPやHやNの下請けで、大企業の古臭いシステムを泥臭く作って、何か起きた時の言い訳のために無意味なExcelファイル量産して。
あー、もう二度と戻りたくない
チューリング完全の言語で、手続き型のパラダイムを含まない言語なんてそうそう無いだろ。
SQLとかのドメイン固有言語でならあるけど、それを「プログラミングを覚える」の文脈で扱うのは違うよな。
厳密にはHaskellとかは手続き型のパラダイム無しで構成されているけど、それでも手続きであるかのように見える仕掛けがあるし。
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓からCUI（コマンドユーザーインターフェース）でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。（追記 すごく間が抜けてたけどMacOSXはUnix系OSです）
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou ＞ aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか？とりあえずやってみよう。ここで＞は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。（追記 ブコメ指摘感謝）
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか７割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
（追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました）
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF（エンドオブファイル）とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
（追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います）
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか？こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
（追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです）
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
このエントリは中からも外からも匿名な感じでお送りしております。中の人を当てられたら1000ガバス。
子供の頃とかはダイヤブロック好きでした。延々ぐちゃぐちゃロボットとか作ってた気がする。
高校まではプログラムとか全然。ゲームやっててあーこういうゲーム自分でも作ってみてーなーみたいな。
大学は行きました。でも情報系じゃなくていわゆる理工系の学部のどっかなぜなら情報系は偏差値が高かったから。大学在学中にサークルとか趣味でプログラミング的なことを始めてあーやっぱこういうの楽しいよなーと思った。製品出てくるまでのライフタイムがほぼゼロで即結果が帰ってくるようなの。ほいでサークルでゲームとか部内サービスとかいろいろ作りました。学んだのはDirectXとかCPPとかHakellとかdotNetとか。あ、プログラミング系のバイトもやってました。覚えてない。CとかSQLとかいじってた気がする。
院にも行きました。ここで本格的に情報系の職業に付きたいのでやっぱ箔は必要かなと思って情報系の院へ。特に後に仕事で直接役に立つ研究はしてなかった気がしますが、とにかく論建ての厳密性みたいなのはサンドバッグになりながら学べた気がします。英語は終始できませんでした。読んだ論文は英語だったけど結局日本語でしか書いてない。
さて就職活動ですが、Googleが応募してるらしいので応募しました。なんかこーあんまり低級なことはしてこなかったのでCとかわざわざ書いて練習した気はします。Haskellよりも100倍早かった。
面接の内容は言えませんけど(新卒でも中途でも同じ基準らしいっすよ)強いて言うなら「XXX(任意の基礎知識)?なんすかそれ？」(面接官に教えてもらう)「それはこういうことでっしゃろか？たぶんこー書いたら実装できます？」みたいな受け答えがウケたんじゃないかなーと思う。自分知識はボロカスですけど知恵には自信あります。
まぁこうしばらく中で過ごしてみて思うのは、のたうち回る能力がまず必要で、次にしんどい時にカードをさっと挙げれる能力とかかなーと。困らないようにする能力と困った時になんとかする能力。結局どうしたって困るので。
やることは超クソ複雑な制約のもとでナイスなシステムを組み上げることで、結局クソ複雑な実装になります。さらにその上で最適化したり既存の機能を壊さないように新機能実装したり。
最近TOEIC受けてないけど900取れた覚えはない。ただTOEIC高得点の人の英語Youtubeで聞いてもアレな感じなことがあるのでTOEICが西海岸の荒野で通じるかは知りません。
技術力がすごい人?そりゃいるんじゃないんですか？ただ僕は圧倒的に人を見る目がないのでなんかみんなすごいって言ってる人はすごいんだろーなーみたいな雑な。でも子供の頃じーちゃんちで泣かされた黒猫より怖い人にはまだあったことがありません。
SQLアンチパターンではないが、デッドロックについても投げっぱなしのあのSELECT FOR UPDATEの説明はなんなのかね。
1回のトランザクションでupdateを2回発行する場合と1回のSQLで複数行のアップデートをする時はデッドロックのリスクを考慮するってだけで、かなり初心者にはありがたいと思うんだけどね。
tA =# begin; tA =# update t1 set column = value where id = 1; tB =# begin; tB =# update t1 set column = value where id = 2; tA =# update t1 set column = value where id = 2; tB =# update t1 set column = value where id = 1; tB =# ERROR: デッドロックを検出しました
tA =# begin; tA =# update t1 set column = value where id = 1; tB =# begin; tB =# update t1 set column = value -- update all record tA =# update t1 set column = value where id = 2; tA =# ERROR: デッドロックを検出しました
あと、先勝ち後負けを実現するのはSELECT FOR UPDATEではなく楽観的ロックな。
tA =# begin; tA =# select updated_at from t1 where id = 1; updated_at ---------------------------- 2019-03-24 06:17:37.952893 tB =# begin; tB =# select updated_at from t1 where id = 1; updated_at ---------------------------- 2019-03-24 06:17:37.952893 tA =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0; UPDATE 1 tB =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0; UPDATE 0
外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか？
外部キー貼らなかったことによって、俺はこんな被害だしたぜっての是非教えてほしい。
すぐに思いついたケースは
とかを思いついたがこんなケースで合ってるのか？こんなケースより間違った外部キーの使い方したほうが家に帰れなくなるケースのほうが多いと思うぞ。間違った使い方をしていて、システムが太ってくるとこんなケースが出てくる。
特に下2つは害悪で、SQLアンチパターンをコピペして、「おまえらw外部キー嫌いはアンチパターンだぞwww」ってやるのもいいけど、同じくらい間違った使い方を注意喚起したほうがいいと思うよ。DB識者のなかでは「そんなの常識w」かもしれないが何もしらない初心者が真似をしてお家に帰れなくなるのは辛くないか？
そんな経験していると、DB初心者は「せや！ユーザテーブルに退会フラグか論理削除フラグ持ったろwww うはw俺天才www」とかなって今度は削除フラグ持つなおじさんが出てくるぞ。しまいにはこれですよ。
http://b.hatena.ne.jp/entry/s/qiita.com/ponkotuy/items/6049388d564fb4385f4e
初心者どうしたらいいんでしょうね(*_*) 是非、DB識者には明るい未来を示して欲しいね。
俺？俺はAndroidのエンジニアでSQLiteは使わないから関係ないね。
RDB初心者の俺が恐れ多くも案を出すと、FKを作成する前に、そのテーブルの性質を予測することが大事なんじゃないかね？大量に発生するログデータなのか、大事なトランザクションデータなのか、第2正規化しただけのただの情報テーブルなのか。大事なトランザクションデータだったら親が削除された時にどこにどうやって退避するか。大量のログデータだったら、親が削除される時どうアプローチするか。とか恐れ多くも予測するね。
ちなみに外部キーないからER図出せないってのはそれはツールの作りであって、FK制約とは関係ないんじゃないの。バリデーション(外部キー)はセキュリティ対策(ER図を作成する)の為、実装するってのと個人的に同じことだと思っている。
Webサーバを管理してるとこんな不正アクセスのログを見ることがあるけど
- - [06/Oct/2016:20:27:30 +0900] "GET /admin/fckeditor - - [06/Oct/2016:20:27:39 +0900] "GET /admin_manage/fckeditor - - [06/Oct/2016:20:27:41 +0900] "GET /admin_manage/fckeditor/t0phackteam/webfuck.shell - - [06/Oct/2016:20:27:44 +0900] "GET /administrator/ - - [06/Oct/2016:20:27:46 +0900] "GET dump.sql
こうやってみんなnetgeekにリダイレクトしよう（Apacheの場合）
Redirect /admin/ http://netgeek.biz Redirect /admin/fckeditor http://netgeek.biz Redirect /admin/fckeditor/t0phackteam/webfuck.shell http://netgeek.biz Redirect /administrator/ http://netgeek.biz Redirect /dump.sql http://netgeek.biz
焼きそば は 雇用契約上の問題からは擁護不可能だけど、blog にもあるように直にお客様を知る貴重な機会だから
「絶対、査定評価には入れない。あくまで任意。代休も用意する」とした上で、少し強めにプッシュするのは良いと思う
が、雇用契約には無いことさせるのに、追い出し部屋はやるとか、アカンやつですやんな
雇用契約にない事をやらせる＝ゼネラリスト として育成し、可能な限り別ポジションを用意するってスタンスでなきゃ
どう言い訳することも出来ないはずだ
でもまぁそれよりも、個人的にはこっちのがキツイ、この会社で働くメリットとは・・・？
開発者はサーバのスペックも、何台で構成されているのかも、どのような場所に置かれているかも知ることができません。sshもできなければログも見れず、メトリクスのグラフを見ることすらできません。ちょっとしたバグの調査であるテーブルのレコード数を調べるのにも、発行するSQL文を添えた作業依頼書を承認リレーする必要がありました
そしたらプレミアム戻ったるわ、端金やし
IT層には嫌われとった
他にはこういうのもあった
引用元：http://hiroki-uemura.hateblo.jp/entry/2015/09/01/230611
さらに開発者はサーバのスペックも、何台で構成されているのかも、どのような場所に置かれているかも知ることができません。sshもできなければログも見れず、メトリクスのグラフを見ることすらできません。ちょっとしたバグの調査であるテーブルのレコード数を調べるのにも、発行するSQL文を添えた作業依頼書を承認リレーする必要がありました。
これらがなぜ必要なのか、いつからこうなのか、誰も知りません。聞いても誰も答えてくれません。しかしながらこのように決まっているのです。
(中略)
最後は総務部を追い出し部屋にしたことです。やめさせたい人間をグループウェアから登録解除し、総務部という名前を持った統合思念体に統一し、PCも共有で1台しか与えない。昨日までエンジニアをしていた人間がスーツを着て社内を歩いて備品の補充をする。そんなことが許されていました。
(中略)
駆け出しのデータサイエンティストもどきです。34歳。昨年から外資ITにて”データアナリスト”として解析部署に採用され、働いています。待遇としては年収950万円。額面からみるとかなり恵まれているのは重々承知しているものの、親や家庭の事情があってもっと稼ぎたいと考えています。具体的には40半ばで1500-2000万。ただ、自分のスキルセットから鑑みると現在はもらいすぎ、または頭打ちに近いのではないかと思っており焦りを感じています。なのでアドバイスをいただけないかと思いここに投稿してみることに至りました。
前職では実装まで行う社内コンサル的な業務を6年していました。データをあちこちからもらってエクセル一辺倒（殆どのデータが100万行に収まったため）で加工分析、インサイトを見つけ施策につなげる等。そこでは高度な統計は必要とされず、四則演算にせいぜい大学教養レベルの数学までで事足りていました。
企画としては投資回収FS、KPI再設定や商流・価格体系改善、在庫予測適正化。システム開発、実装に伴う社内外折衝、効果測定。上層へのレポーティングなどなど。内4年間は海外において販社立上げ、地域統括会社での予実管理から現場部隊管理、飛び込み営業まで雑多にやっています。ただ、読んでおわかりいただけるように散漫とした経験です。1社目は重電会社での設計を6年していましたが、企業人としてのいろはを除けばこの経験は現在ほとんど使われておりません。。。
ほぼできません。遅ればせながら最近始めました。SQLを習い、何て便利なツールなのか！！と感動しながら毎日嬉々としてこねくり回しています。幸運にも現在の会社にはDWHがあり、すぐに活かすことができています。あんなに加工に苦労していたデータが一瞬で結合・集計されて出てくる快感。。。業務範囲でも需要予測、異常検知などをMLに置換する動きがあり、幸運にも機械学習スクールに通わせていただくことになりました。実務にもすぐ使えそうなのでとても楽しみにしています。汎用性のある技術を習得することで自身の市場価値が高まるのではないかと期待しています。ただ軌道にのってもプログラミングがそこそこ使えるようになるまでには少なくとも3－4年かかるのかなあと思っています。見積もり甘いでしょうか。そのころには40手前。難しい分野と認識しており、自身の能力的に凡庸なレベルでしか体得できないないし挫折する可能性もあります。
さて、冒頭に書いた収入を目指すための選択肢としては①現在の会社で出世する、②現在のデータアナリストとしての実力を磨き海外に挑戦、③国内他社へ転職、④起業、⑤副収入先を作るでしょうか。
②は給与が高いアメリカを想定しています。しかし、技術力もないし英語もネック。シンガポールでなら何も不便なかったけれども、英語が母国語の国で渡り合っていくには非常に厳しいと感じています。(TOEIC970) 1on1ならアメリカ人相手でも何時間でも会話できますが、相手が2人以上になると格段に難易度が上がる。。。幼子が2人いる上、海外に挑戦するには年齢もそろそろネックだなあと。シンガポールなら給与的にも実現可能性的にも良いのかもしれません。それ以外ではプログラミングスキルと実績を上げて①か③、というのがある意味王道でしょうか。
そもそも、日本におけるデータサイエンティストの給与レンジはこれからの5年10年でどれくらい伸びるでしょうか？アメリカではジュニアレベルで6桁スタートで、チームリーダーなら中央値35万ドルだそうです。夢がある。
https://www.kdnuggets.com/2019/02/data-scientists-expensive-hire.html
一方、次の記事によれば日本では40台で655万程度。信頼性は不明ですが現在の自身の給与から考えるとあまり伸びしろは期待できないように感じてしまいます。
https://heikinnenshu.jp/it/datascientist.html
少しでも増やすために、雇われ以外の副業も考えてはいますがなんとなく踏み出せていない状況です。まとまってない文章ですみません。
日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。
https://anond.hatelabo.jp/20190205192741
COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。
SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLのコンパイル単位で、それごとにソースファイルが分割される。ひとつのソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLにコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。
で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイル。sedやawkでテキストファイルやCSVファイルを行ごとに処理するのとちょっと似てるけど、COBOLの場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的なデータの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だからUIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。（混乱するから余談だけど、今のCOBOLはSQLを使って普通のRDBにもアクセスできる。ただ使い方としては、RDB→ファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初と最後だけみたいなのが普通）
入出力がファイルだから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグや不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。
データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOLプログラム側、というのがSQLと一番違うところかも。つまり、このデータファイルの構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。
まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行や官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通の大企業は途中でSunとかに置き換えてその後Linuxやクラウドにさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題。
を狙ってるそこのお前
どうせお前のスキルセットは「html,css,js,rails」だろ？
揃いも揃ってそんなんばっかり
HTTPメソッドもSQLも理解せずにそれっぽく動くN+1だらけのクソ作っただけだろ？
webプログラマ目指すくせに開発環境構築にDockerも使わず理解してないコマンドをコピペしてローカルに直でインストール
せっかく無料枠あるのにawsじゃなくてHerokuにプッシュするだけのデプロイ
ブランチ運用なんて考えずmasterブランチに直プッシュか？
会社に入れさえすれば先輩がつきっきりで教えてくれるとでも思ってんのか？
先輩を質問責めにする気か？
むりむりやめとけ
そんなんじゃせいぜい年収300
諦めた方が身のため
あばよ
どうしてもなりたいなら↑で挙げたものぐらいは最低限を理解しとけ
ここまで言って調べる気にならないなら本当に向いてないよ
