
きょうは、PythonとSQLの境目をどこに引くかを決めていきます
Pythonがひととおり書けるようになると、ここで迷います。
「SQLも覚えないといけないのか」
「pandasで全部できるのでは」
正直、覚えることが増えるのはつらい


わかります。なので「両方やろう」ではなく「どこで切り替えるか」の話にします
線が1本引ければ、迷いは消えます。
ここは、大人の学び直しで効き方がはっきり出るところです。
学生時代は、範囲を全部やるのが正解でした。
時間があり、抜けは減点に直結したからです。
大人は逆です。
時間が有限なので、「全部やる」を選んだ時点で終わらなくなります。
覚えるべきは両方の全体像ではなく、切り替える1点だけです。
結論:線は「データを動かす前か、動かした後か」
SQLは、手元に持ってくる前に減らす道具。
Pythonは、手元に来たものを調べる道具です。
この一線で、ほとんどの判断がつきます。
絞り込み、結合、集計。
これらは向こう側で済ませるほうが速い。
欠損の補い方、外れ値の判断、可視化、モデル作り。
これらはこちら側でやるしかない。
なぜそうなるのか。
理由を見ておくと、応用が効きます。
なぜ「向こう側で減らす」ほうが速いのか
理由は3つあります。
① メモリに載る量には上限がある
pandasは、原則としてデータを全部メモリに置きます。
1億行のテーブルを、そのまま読み込むことはできません。
SQLなら、必要な行と列だけを取り出せます。
1億行から1万行にしてから渡す。
これだけで、詰まりが消えます。
② データベース側は、検索のために作られている
索引を張り、実行計画を立て、最短の道を選ぶ。
これはデータベースの本業です。
同じ絞り込みをPython側で書くと、全件を運んでから捨てる形になりがちです。
運搬の時間がまるごと無駄になります。
③ 結合はSQLのほうが素直に書ける
表を突き合わせる、まとめる、入れ子で絞る。
SQLは、そのために作られた言語です。
同じことをPythonで書くと、行数が増え、間違いも増えます。
できるけど、向いてないってことか

そういうことだと思っています。
1つの分析を、実際に割り振ってみる
言葉だけだと掴みにくいので、流れに沿って並べます。
① 取り出す(SQL)
↓
② 形をそろえる(SQL)
↓
③ 読み込む(Python)
↓
④ 調べる(Python)
↓
⑤ 図にする(Python)
↓
⑥ モデルを作る(Python)
①では、条件に合う行と、使う列だけを選びます。
②では、日付の形をそろえる、空欄の扱いを決める、といった下ごしらえをします。
ここまでを向こう側で済ませるのが、効く。
③から先は、Pythonの領分です。
SQLの結果は、そのまま表として読み込めます。
④以降は、判断が入る作業です。
この値を異常と見るか。この列を新しく作るか。
「決めながら進む」部分は、SQLには向きません。
PythonのなかにSQLは書けるのか
書けます。
むしろ、実務ではこの形が中心になります。
import sqlite3
# データベースにつなぐ(無ければ作られる)
conn = sqlite3.connect('example.db')
c = conn.cursor()
c.execute('''
CREATE TABLE stocks (
date text,
trans text,
symbol text,
qty real,
price real
)
''')
c.execute("INSERT INTO stocks VALUES ('2023-05-30', 'BUY', 'RHAT', 100, 35.14)")
conn.commit() # 保存する
conn.close() # 必ず閉じる
やっていることは3つだけです。
つなぐ。命令を送る。閉じる。
最後の「閉じる」は、忘れると詰まりの原因になります。
ここだけは癖にしておいてください。
相手がSQLiteでなくても、形は同じです。
つなぐ部分が変わるだけで、送る命令はSQLのままです。
SQLを一切書かず、Pythonだけで押し切れるか
ここが、最初の問いへの答えになります。
結論から言えば、押し切れます。ただし、データが小さいうちだけです。
CSVを読む。数万行を扱う。
この範囲なら、pandasだけで何も困りません。
問題は、規模が上がったときに書き方ごと変えることになる点です。
作り直しになるってこと?


全部ではありません。ただ、取り出し方を後から替えるのは、地味に面倒なんです
そして実務では、こういう場面が来ます。
「同じ集計を、毎月出してほしい」
「他の人にも使わせたい」
そのとき、取り出しがSQLで書いてあると渡しやすい。
SQLは、この業界で共通語だからです。
ORMを使うなら、SQLは要らないのか
SQLAlchemyのようなORMを使うと、SQLを直接書かずに済みます。
ただし、これはSQLが消えるのではなく、自動で作られるという意味です。
遅くなったとき、何が生成されたかを読むことになります。
そこで読めないと、手が出せません。
ORMは、SQLを知らなくても書ける道具ではありません。
SQLを知っている人が、書く量を減らすための道具です。
どこから覚えれば足りるか
最後に、現実的な範囲を書いておきます。
分析のためにSQLを使うなら、まずはこれで足ります。
SELECT/WHERE/GROUP BY/JOIN。
4つです。
テーブルを作る側の知識は、後からで間に合います。
PythonとSQLは、競合しません。
減らす係と、調べる係。
役割が違うだけです。
だから、どちらかを選ぶ必要はありません。
切り替える場所さえ決まっていれば、それでいいと思っています。
そして、4つも一度には覚えられません。
それで普通です。使いながら戻ってくれば定着します。
その回数の話は、知識の定着率は、繰り返した回数で決まりますにまとめました。
大人の勉強で効くのは、一度に詰め込むことではなく、戻る回数のほうです。
