  |
はてなキーワード: SQLとは
ぎくりとした。私も数ヶ月前から精神科に通院しているからだ。ADHD疑いで。
ADHD。
子供の頃から忘れ物、遅刻、約束忘れ、すごく多かった。成績は良かった。大学も行けた。就活もして都内大手企業に内定。苦手なことは3倍かかったし、ミスも多くて怒られた。みんなが出来ることが出来なかったが、幸いプログラムが組めた。Excel、VBA、SQL、Python…コイツらのおかげで出世はできなかったが、仕事はできた。
子供が産まれると予定が増える。1人目。まだなんとかなった。癇癪がすごい。子供の泣き声がすると2回警察を呼ばれた。殴ってない。むしろ殴られてた。2才だった。
2人目。
もう全然回らなかった。仕事。家事。育児。びっくりするくらい予定を忘れた。保育園の連絡帳。記帳がないからプールに入らなかったと言われた。ごめん。保護者面談2回忘れてた。PTAの仕事。やらなきゃとわかっているのに手が動かない。もう、もう、ダメだった。
でも障害者になるのが嫌だった。
精神科に行った。病院で薬をもらって飲んだら嘘みたいに頭がスッキリした。毎日未完了のタスクがぐるぐるしていた頭が真っ白になって、タスクに取り組めた。
もう。認めるしかなかった。
この子も苦しむのか。知らずに産んでごめん。友達と一緒に遊んで悪気なく手を挙げたりするって。聞いたよ。私も全く同じことを子供時代にしていた。
ごめん。ほんとに。なんで知らなかったんだ。これから先、すごくすごく苦しいだろう。
私は友達と話す時、会社の同僚と話す時、素で話せたことはない。学習して学んだ適切な振る舞いをして過ごしてきた。だからすごく疲れるし1人になりたかった。今もそう。家族にもそう接してる。良い母の顔でずっと探してる。素の自分じゃ誰も好きになってくれない事を知ってるから。お母さん以外素の私を好きになってくれる人はいなかったから。
こんな文書いて何したいのか。
本当にごめん。ごめん。ごめんよ。
ADHDってどこかに居場所があるのか？薬を飲んで健常者のふりをしても、それは私じゃない。ずっと自分を否定ながら、明るいフリをして、元気なふりをしてこれから先生きていく。子供も。
療育を受けましょう。と、先生は言った。療育。健常者の考えそうなことだ。特性を理解して付き合いましょう。もう、いやだいやだいやだいやだ
ぎくりとした。私も数ヶ月前から精神科に通院しているからだ。ADHD疑いで。
ADHD。
子供の頃から忘れ物、遅刻、約束忘れ、すごく多かった。成績は良かった。大学も行けた。就活もして都内大手企業に内定。苦手なことは3倍かかったし、ミスも多くて怒られた。みんなが出来ることが出来なかったが、幸いプログラムが組めた。Excel、VBA、SQL、Python…コイツらのおかげで出世はできなかったが、仕事はできた。
子供が産まれると予定が増える。1人目。まだなんとかなった。癇癪がすごい。子供の泣き声がすると2回警察を呼ばれた。殴ってない。むしろ殴られてた。2才だった。
2人目。
もう全然回らなかった。仕事。家事。育児。びっくりするくらい予定を忘れた。保育園の連絡帳。記帳がないからプールに入らなかったと言われた。ごめん。保護者面談2回忘れてた。PTAの仕事。やらなきゃとわかっているのに手が動かない。もう、もう、ダメだった。
でも障害者になるのが嫌だった。
精神科に行った。病院で薬をもらって飲んだら嘘みたいに頭がスッキリした。毎日未完了のタスクがぐるぐるしていた頭が真っ白になって、タスクに取り組めた。
もう。認めるしかなかった。
この子も苦しむのか。知らずに産んでごめん。友達と一緒に遊んで悪気なく手を挙げたりするって。聞いたよ。私も全く同じことを子供時代にしていた。
ごめん。ほんとに。なんで知らなかったんだ。これから先、すごくすごく苦しいだろう。
私は友達と話す時、会社の同僚と話す時、素で話せたことはない。学習して学んだ適切な振る舞いをして過ごしてきた。だからすごく疲れるし1人になりたかった。今もそう。家族にもそう接してる。良い母の顔でずっと探してる。素の自分じゃ誰も好きになってくれない事を知ってるから。お母さん以外素の私を好きになってくれる人はいなかったから。
こんな文書いて何したいのか。
本当にごめん。ごめん。ごめんよ。
ADHDってどこかに居場所があるのか？薬を飲んで健常者のふりをしても、それは私じゃない。ずっと自分を否定ながら、明るいフリをして、元気なふりをしてこれから先生きていく。子供も。
療育を受けましょう。と、先生は言った。療育。健常者の考えそうなことだ。特性を理解して付き合いましょう。もう、いやだいやだいやだいやだ
正解が「数学的」に決まるところ。たとえば「1■1=2 のときに ■を答えなさい」というときに競プロは■を答えるだろうし、それを早く答えて悦に入るだろう。
それもいいけど、いちど数学的に答えが決まっちゃう問題はライブラリにまとめられて、一般的なコーダはなにも考えなくてもインポートして処理できちゃうわけ。上の例えだとふつーのプログラマなら「枯れたライブラリをインポートして、正しく答えが出ると確信できるなら『答えは正しいとか考えなくても』それを使って対処する」ので、データの振る舞いとか気にしないで済む。たとえば SQL なんて、実行時計画という「アルゴリズムを常に指定するなら不要な」話題があるのだけど、データ量によって適切なアルゴリズムが変化するから仕方ないし、概ね RDB は賢いのでヒューマンが考慮するのは問題がある場合だけなのだ。よって、競技プログラマが生産性を確実に上げるという根拠はない。
もちろん、アルゴリズム知識を身につけるのは大切だし、クヌース先生も書いてたけど分散処理アルゴリズムはフロンテイアだろうよ。というか、暗号分野やセキュリティの領域や、条件が過酷な場合（宇宙線の影響下とか、メモリの少ないエッジコンピューティングとか）だと、アルゴリズムの研究や追求は大切なのは今も同じだ。でも、競技プログラマが新規にアルゴリズムを開発したり、セキュリティに向上したという話は聞いたことがないが、レッドコーダー諸君は自前で創造して使われた実績はあるのだろうか？
ついでに聞いてみたいのだが、競技プログラマたちは「マルチスレッドなコードで早く書こうとしないのはなぜ？」「そもそも、競技プログラミングで使うコードは便利なスニペッツがあるけどそれってチートでは？」「ときどき正規表現で解く問題があるけど、そのときの計算量は無視してない？」という矛盾を抱えているのてはないか？と思うのだが如何か。
究極的には競技プログラミングに必要な知識というのは、産業用途で要求される知識の一部でしかないのが問題なんだと思うよ。ほら、アレだよ、むかし話題になった「数学だけデキる人向けの東工入試をやったら、英語ができなくて卒業できなかった」という童話に近いんだよ。競技プログラムってインとアウトしか見てないブラックボックステストだから、ここだけしか計算機科学の知識が無いというヤバ人材の育成しかなってないのだろうな。
マドンナとか、蒼井そらとか、元AV女優のイタリアの議員とかみたいに、クレイバーでタフだったり、
ガガとかみたいにそもそも実家がゴン太でもないのに、なんとなくで風俗嬢や類すること(水商売等)をしている人は、
明確に知能や判断能力に問題があると思ってるし、セックス産業(物理)は無くなった方がいいと思ってるやで
理由は2つ
金ないからウーバーイーツやると同じくらいの狂気を感じる(車やバイクの運転が何よりも好きでめちゃくちゃ運転も経路選択も上手い人は別)
もしくは半世紀くらい前の世界や法が及ばない後進国からやってきたとか
金が無いからこそ健康優先でデスクワークだろうにな
セクキャバで時給2000ー2500円とかみたけど
都内ならSQL叩ければ普通に出る額だぞ
もちろん、死ぬほど車／バイクが好きだから宅配やるぜと同じく、
死ぬほどセックス全般を愛していてセックススターになりたいっていうなら別だが
おそらくそうではなかろうよ
若い頃に楽して稼いじゃったからだぞ。風俗だけじゃなくて水商売も同じ
水商売の接客が出来るなら、同性の同僚はともかく(フツーにキャスト同士で揉めてるし)
異性の同僚や上司なんて転がし放題よ
転がしまくって初アサインでフルリモートかつ残業ゼロの仕事を勝ち取った人おったよ
やり甲斐やスキルアップやある程度の給与求めるなら、英語が出来るんだし、
◯◯やった方がいいとかXXやった方がいいって言ったけど、
子どもがいるから家にストレス持ち帰りたくないとか言ってやらないよね
苦労する＝スキルアップ出来る ではないので、無駄な苦労はしない方がいいが、
文明人としての建前は守らなきゃいけないのでリンクは貼りませんけど
まぁこれは一例で、親子二代AV女優だったり、風俗嬢だったりなんてのもあります
ウシジマくんにも似たような話あったなぁって思います
もちろん、現実で仕事に思い悩むセックス産業の女性と面と向かったとしても、
必死に自分で生活を立てようとしている彼女たちをがんばったねって肯定し尊重するフリをすると思います
『お前の知能で考えたことはまともじゃないので従いなさい』なんて絶対言いません
我が身がかわいい以前に、頑張って生きている人を面と向かって蹴り飛ばすとか、人生全否定とか、フツーは出来ないです
割とクソどうでもいい記事だった。
日本語と英語で述語・目的語の並び順がちがうけど英語の順番の方が性に合ってるよね、てな具合の話。
じゃあ検索の効率も出来る事も事実上向上する可能性は全く無い。
https://anond.hatelabo.jp/20240507125309
はい。
ではなく、SQLは処理じゃなく、定義であることを理解するのが大切。
何の定義かと言えば、リレーショナルデータモデルへの演算定義なんだよ。この演算には、関係代数という演算を使う。
なぜ定義だと認識する必要があるかという、Selectは出力でも何でもなく、射影という演算の一部なんだよ。
"+3" とかと一緒
で、関係代数演算は順位にもちろん意味がある。最初に"射影"して"選択"かけたら全く別になる。
SQLは、この演算順位を、SelectやWhereの中で状況によって意味が変わる。という出鱈目なカバーで逃げた。Order byで悩んだろ。
さらに言えば、苦肉の策でWhereのパチモンはどうしても2回必要でHavingを作ったのよ
本来で言えば、この演算は、選択-結合-射影-結合といくらでも出来る。
「足し算は頭に一回書いてください。複数使う時はかっこつけて下さい。ちなみに、掛算を一緒に使うと足し算の意味が変わり場合によってはエラーです」みたいな安直な構造定義しちゃってるの。
リレーショナルモデルへの演算としてだダサダサで、リレーショナルモデルの演算の複雑さではなくSQLという表現の都合で人類の頭に負荷かけ続けてる。
出力が頭にあるのは便利(間違い)。英語だから(間違い)。って言われると何言ってるんだーって、ちょい昔のまともなデータベースエンジニアなら普通にキレてた案件
dbplyrは知らないけど、こういうORMによくある
でもだったらGUIツールでSQLの出力部先にある程度組み立てて支援使えばよくね？とも思うので
順序性でわからないって言われれるといや、プログラム考えるときの思考と同じ順序では？になるので
何が言いたいのかわからんになるの
使うテーブルがどこになるとか項目名がどうなるかが、from以降書いてからじゃないと判断しにくいことが多いので
処理書くときの最初にselect句の内容が書きにくいってことは結構あると思う。
https://www.docswell.com/s/hoxo-m_inc/Z4Q8NL-2024-05-06-203800#p11
出力が先に来ることが分からないって言ってるけどプログラム書くとき殆どの言語においては出力が先に来ると思うんだけどそれもわからないんだろうか
public String test(String args){
return args;
}
大抵戻り値（出力）が先で引数（入力）が来て処理が来ると思うんだけど違う？
プログラムを書くときって出力の要件を元にして処理と入力が決まると思うんだけど違う？
シーケンスとか書くと確かに入力が元に来るんだけどプログラムの当初設計をするときは出力が先で出力を得るための入力と処理が決まる物だと思うんだ
入力を決めて処理と出力を考えてたら考慮漏れ発生して手戻り発生しない？
補完がやりづらいからっていうのはわかるけど、そんなんFROM句先にかけよで終わると思うので
https://b.hatena.ne.jp/entry/s/www.docswell.com/s/hoxo-m_inc/Z4Q8NL-2024-05-06-203800
まともにコンピューターサイエンスやってSQL使ってれば
「わかるー射影はステップの最後なのに、selectに名前変更とか拡張とか全部乗せて先に書くのキモいよねー」
の一言で終わりなのよ。
ブクマカは、英語ですからとか言い出してる。英語だからって集合演算で射影を先に書くなんてねえよｗ
やばいSQL使ってるのに、SQLで実現してることが分かってない。さらには俺はSQLに詳しいとかいう雰囲気出しててやばいｗ
高度な話題？なわけねえだろwiki読むだけでいいレベルなのよ。
https://ja.wikipedia.org/wiki/%E9%96%A2%E4%BF%82%E4%BB%A3%E6%95%B0_(%E9%96%A2%E4%BF%82%E3%83%A2%E3%83%87%E3%83%AB)
X検索すると似たような言及してる奴が多いし、別に高度な問題でも何でもないのである。というか基本情報の範囲。
こんなのがテクノロジーカテゴリでマサカリなげてる。一般カテゴリの劣化はどっちかつうと過激なんだけど、テクノロジーカテゴリは明確に馬鹿が進んでる。
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、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などに切り替えていく、というプロセスがいいのではと個人的に思います。
