【SQL】コマンド和訳キャラ解説([SQL] Japanese translation of command + character explanation)

各コマンドをキャラ解説風に単純和訳します。主観のみ。腹落ちしないと理解が進まない…。


SELECT(選択)

間違いなく主役、このひといないと表示もされません。フル装備「*」にすると、ダブル主演のFROM次第でめっちゃ着ぶくれする(列の量)。


FROM(~から)

SELECTはFROMがないとキャラ立ちもしないので、重要度的にダブル主演。能力的には原作&元ネタ(正確にはデータ元)だけど、UNIONやJOINやサブクエリでいくらでも()内深くできるので腹黒い。


WHERE(どこ)

ガチガチに縛れる鎖。あなた以外いりません、って意味では一途。腹黒さあり。その強さゆえにキャラでは主役級だけど常に必要でもない。相手の性質を調べる。(1:1)


GROUP BY(グループ化)

膨大データに絶大な効力を誇るまとめ役。そのかわりSELECTに「*」が使えなくなる。HAVINGのお目付け役でもある。


HAVING(持っている)

GROUP BYがいないと出演できないサブキャラに分類されがち、だけど使い方で秘密兵器になるくらいの能力を持つ。GROUP BYとのタッグで集合体の性質を調べられる。(1:複)


ORDER BY(注文)

某アイドル番組の「オーダー!」を思い出します(Z世代以降は知らないかも)。今のところ昇順・降順の役しかないけど、ORDERの考え方自体はウィンドウ関数にもあるので要キャラ。


LIMIT(限界)

結果多いから〇行だけ見せて、とお願いします。サマリというにはおこがましいか…。


CASE-WHEN-THEN-ELSE-END(ケースーいつーそれからーほかにー終わり)

使いこなせるかどうかが初級と中級の分かれ道、プロはHAVINGじゃなくてSELECTで分岐させる(by参考書)。式の仲間なのでどこにでも書けます、入れ子にもできる。END忘れがち。ELSEはNULLでも書いた方がいい。


NULL(ヌル)

私がSQLを好きな理由、一番。厳密には「未知」と「適用不能」の2種がある。値でも変数でもないジョーカー、比較言語を適用するとすべて「unknown」になり破壊されるw


ウィンドウ関数や結合までキャラ化する気力が足りなかった。

理系学校でプログラミング習ってましたが、最初から遅れてました。C言語メーンだったかな、電子科でしたからね…。include(呪文か)、if、ループ、アルゴリズム、正直仲良くなれる気がしなかった。

SQLを学んでいて、あ、こっちのほうが好きだ、と気付きました。CやJavaゴリゴリ書ける人はSQLに違和感あるらしい。プログラミング言語が真偽の2値を基礎とするのに対して、SQLは「unknown」を加えた3値論理です。

データ分析ではNULLの扱いが肝、ゴミからはゴミしか生まれない。と習いました。ゴミにも宝があるのでは…とひねくれた自分は思いましたが、そもそも完全なるデータって存在しない。集められた時点でバイアスが入っている。これは公的統計にすら言える現実です。

分析の8割はデータラングリング(=クレンジング・整形)で決まるという。なので現在はSQL重視で勉強中です。BIツールは見目好くデザインするには最適ですが、元データがないと何にもできない。NULLをいかに適切に処理するか、プロでも悩む基本に忠実にありたく、せめてSQL初心者は脱却したい。


********


Translate SQL commands to Japanese in character style. Only subjective. If I don't understand it myself, I can't learn.


SELECT

This person is undoubtedly the main character and would not be undisplayed. If you set it to full equipment "*", it will be very bulky depending on the FROM (the number of lines).


FROM

SELECT has no character without FROM, so it is inevitably a leading role. Its capabilities are close to those of the original (data source, to be precise), but it can do as many deep things as it wants with UNIONs, JOINs and subqueries, so it's cunning.


WHERE

A chain that can be tied tightly. If you interpret it as ``I don't need anyone but you'', then it is single-minded. It is a main character because of its strength, but it is not always necessary. You can check having it the nature of opponent. (1:1)


GROUP BY

An extremely effective organiser of large amounts of data. You cannot use "*" in SELECT. It is also the guardian of HAVING.


HAVING

Since it cannot be used without GROUP BY, it tends to be classified as a sub-character. But depending on how you use it, it can become your secret weapon. By tagging with GROUP BY, you can explore the properties of the aggregate. (1: multiple)


ORDER BY

It reminds me of a certain idol show called "Order! (Generation Z and above may not know this). At the moment there are only ascending and descending roles, but the idea of ORDER is also in the window function, so it's a necessary character.


LIMIT

When I need "Please show me some of the results". I guess it's too presumptuous to call it a summary.


CASE-WHEN-THEN-ELSE-END

The difference between beginner and intermediate is whether you can master it, and professionals use SELECT instead of HAVING (according to the reference book). Since it is part of the ceremony, it can be written anywhere. I often forget END. It is better to write ELSE, even if it is NULL.


NULL

Why I love SQL, the number one command. Actually, there are two types: "unknown" and "not applicable". A joker that is neither a value nor a variable, when a comparison language is applied, everything becomes "unknown" and destroyed lol


I didn't have enough energy to make the window functions and connections into characters.


I learnt programming at science school, but I was behind from the start. I guess it was mainly C, as it was an electronics department... Include, if, loop, algorithm, to be honest, I didn't feel like we were going to get along.

When I learned SQL, I realised I liked it better. People who are good at writing C and Java seem to find SQL strange. While programming languages are based on binary values of true and false, SQL is based on three-value logic with the addition of 'unknown'.

When it comes to data analysis, dealing with NULLs is key, and garbage produces nothing but garbage. I learned that. I thought there might be treasure in the garbage, but there is no such thing as perfect data. There is bias at the point of collection. This is true even of official statistics.

It is said that 80% of analysis is determined by data wrangling (= cleaning and shaping). That's why I'm currently studying with a focus on SQL.

BI tools are perfect for creating designs that look good, but they can't do anything without the original data.

I want to stay true to the basics of how to properly handle NULLs, which even professionals worry about.

DATA idm8

Aim for a comprehensive analysis. Data-informed decision making. データ分析/著作権・知的財産マネジメント