  |
はてなキーワード: sqlとは
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
ウチにはテレビが無いのにいつ頃からか息子がピカチューと言い出した
どこで覚えてくるのだ
幼稚園だろうか？好きなだけ触らせているタブレットか？知らんが、
ドハマる
（本人曰くは鉄道趣味も並行してしるらしい、夢は大宮の鉄道博物館にEF55を見に行くこと）
数週間はTVアニメで満足していたが俺のスマホをチラ見したときポケモンGOの広告が見えた
だーかーらー、そういう知識はどこで仕入れてくるのだ、すげぇな最近の５歳
秒速ドハマる
スマホを返してくれない
ポケモンGOを簡単に説明すると、スマホのGPS位置情報と連動し画面上に抽象化された実際の町と同じ地形が現れ、スマホが移動すれば画面上の位置も移動する、ポケモンがランダムに現れる、ボールを投げて取る、沢山取れば進化や強化ができる、たまに珍しいポケモンも現れ、様々なタスクをクリアすることでも獲得できる
恐らくサーバー側ではSQLでユーザーデータ管理しているだろう
管理者であればSQLコマンド一発でレベルアップだろうがポケモンコレクションだろうがどうにでも操作できる
データベースのどこかのレコードのなにがしらのテーブルの数値を変更するためにちまちまちまとアホらしい作業をやってる
と子供にもわかるように意訳し諭したが「ぼく子供だからそういう難しいことはわからない、それよりパパ見て超珍しいポケモンゲットした、飴が集まったから進化できるよ」
仕方がないので余っていたスマホを息子用に再整備し、バカだからどうせすぐに壊すだろうからハードケースに入れてセットアップしてアカウントも作り直した
それから早半年が過ぎた、まだブームは続いている、俺と息子のPL（ポケモンレベル）は３９まで成長した。スマホは傷だらけだがまだ壊していない。
レイドパス（一日１枚付与される特別な戦闘チケット、勝利するとレアなポケモンを取得できる）をスルーして流したことは一度も無いのではなかろうか。毎日やってる
俺の自転車の後ろに乗り、あっち行け、こっち行けと指示され俺は自転車を漕ぐ
俺は画面も見れないので俺が取りたいポケモンが出たら後ろから息子が教えてくれる仕組み
だが、ある日教えてくれてない事に気づいた、
問い詰めたらパパだけレベルアップ進むのズルいから、らしい、かわいいなぁ
ポケモンGOにはゲーム内コインがあり、集めると有利なアイテムが手に入る
クレジットカードで購入することもできるが自力で貯めることもできる
そのためにはジムにポケモンを配置しなきゃならない、一日最大で５０コイン取得できる
長い時間ジムに滞在させたほうが多くコインが貰える、他のユーザー（トレーナー）に攻撃されてジムを乗っ取られるとそこでリセット（ポケモン返却＋それまでの時間のコインをゲット）となる
一箇所のジムに最大６匹（同一ユーザーは１匹）まで配置することができる
俺は子供が寝た後に近隣のジムに赴き（町中に点在している）、既配置されている他人様のポケモン達をぶっ殺しジムを乗っ取り俺と息子のポケモンを配置する
俺なにやってんだ？
俺の時間単価から考えたらクレカでサクッと購入したほうが合理的だが
そういうものではない、それをやっちゃお終いだ、ゲームをやる意味が無い
Bluetoothでスマホと接続しちまちま手作業でポケモンを取らなくても全自動で周囲のポケモンを根こそぎ取ってくれる
こーゆーの使ったら意味ねぇのよ
というか、ポケGO初めてから数日後にアホらしくなりどうせアカウントマーケットがあるだろうと検索したら案の定ある
引退した人などの育成とポケモンコレクション済みのアカウントが売られている
でも、そーゆー事したら意味ねぇのよ
息子と自転車で走り回り一喜一憂するのがプライスレスなの、楽しいの
ともかくそういう思いで集めたコインだが、コインはある程度貯めてからアイテム交換（購入）したほうが割引率が高い
どう考えても後者がお得で、それ以外にもコインはある程度貯めたほうが良い
戦闘用のレイドパスよりもゲームを快適有利に進めるため先に入手したほうが良いアイテムもあるのだが、５歳のバカは１００コイン貯めるとそっこーでレイドパスに交換し戦闘をする。
アホだ
何度説諭しても聞きやしない、まぁ好きにすりゃいい
戦闘（バトル）するとポケモンが弱ったり死ぬ（正確には気絶、ポケモンの世界ではポケモンは死なない、平和だね）
回復には回復アイテムが必要、これもゲーム内で一定作業をしなければ手に入らない
俺は勝手に溜まっていくので回復アイテムは常に捨てるほどあるが
息子は、バトルする、負ける、残ってる弱いポケモンで再戦、当然負ける
これを繰り返し、ポケモンは最大３００匹持てるのだが全滅するまで諦めない、アホだ
回復アイテムを入手するにはフォトディスクをちまちま回すかフレンド（ゲーム内のユーザーリレーション）とギフト交換しなきゃなんないが、そーゆー作業は面倒くさいとやりたがない
これも俺が夜にこっそりやってた
すると数週間で全滅状態が無くなった、タコなりに学習したようだ
そんなこんなしていると気づいたら足し算と引き算と掛け算を習得しやがった
我が家は非認知能力全振りの方針なので認知能力的学習はほぼほぼやらせてない、が
コイン管理などゲーム進行には四則演算が必須で、数字概念の学習導入、誘導はしてやったが、なんか知らんうちに３桁の足し算と引き算は暗算している、掛け算の概念もどうやら分かっている模様
ポケモンすげぇな
レイドで俺だけ取れて息子が取り逃がしたら発狂して面倒なので息子が取れたことを確認してから俺も取っていたんだけど、いつからかこれも無くなった、パパ良かったね、ボクは取れなかった残念、なんて言うようになり、前頭葉、精神的成長の証か
と喜んでいたらパパからポケモン交換でぶんどるからいい、だってさ
町中で同じようにポケGOをやってる少年たちと遭遇することがあるが
息子は臆することなく話しかけて「ポケモンやってるの？フレンドにならない？」って、そこからポケモン談義してる、すげぇな５歳のコミュ力
幼稚園にもポケモングループがあるらしく日がな一日ポケモンの話をしているらしい
スマホみせっこ自慢大会に連れて行かされる、飽きると走り回って謎のポケモンゴッコ
パパ友ネットワークができた
若い頃に楽して稼いじゃったからだぞ。風俗だけじゃなくて水商売も同じ
水商売の接客が出来るなら、同性の同僚はともかく(フツーにキャスト同士で揉めてるし)
異性の同僚や上司なんて転がし放題よ
転がしまくって初アサインでフルリモートかつ残業ゼロの仕事を勝ち取った人おったよ
やり甲斐やスキルアップやある程度の給与求めるなら、英語が出来るんだし、
◯◯やった方がいいとかXXやった方がいいって言ったけど、
子どもがいるから家にストレス持ち帰りたくないとか言ってやらないよね
苦労する＝スキルアップ出来る ではないので、無駄な苦労はしない方がいいが、
ワイの謎のフォロワー(風俗嬢)に言いたいこと
理解ある彼くん・パパくんの登場をお待ちいただくか、本人が変わる気になるまでどーにも出来ないが、
特別美人・かわいいワケではなくて、そこそこ接客と勤怠そこそこしっかりしてる人なら、コミュ障だらけのITで無双出来るぞ
本業ではなく副業でやってるわけわかんね〜ヤツのレベルの収入なら速攻でITが上回るようになると思うよ
未経験でも売り方間違えなきゃ400万以上狙えるし、将来的には600〜1000万全然狙えるで
セックスが好きで好きで仕方なくて天職だと思っているわけで無いなら、無駄に自尊心削られるだけだしすぐにおやめなさい
例によって例のごとくメンヘラってるみたいなのでどこまでお話本当か知らんが(メンヘラ営業だったりして)、
金ないからウーバーイーツやると同じくらいの狂気を感じる(車やバイクの運転が何よりも好きでめちゃくちゃ運転も経路選択も上手い人は別)
もしくは半世紀くらい前の世界や法が及ばない後進国からやってきたとか
金が無いからこそ健康優先でデスクワークだろうにな
セクキャバで時給2000ー2500円とかみたけど
都内ならSQL叩ければ普通に出る額だぞ
もちろん、死ぬほど車／バイクが好きだから宅配やるぜと同じく、
死ぬほどセックス全般を愛していてセックススターになりたいっていうなら別だが
おそらくそうではなかろうよ
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
