OpenPNEというよりSQLの修業中か。
ダミーユーザを作ってコミュニティに入って書き込む練習などをした後 ダミーユーザの退会を行なうとそのコミュニティから消えはするが コミュニティの人数カウントが減らない。comminity_member に残りっぱなしだから。そのうち直るんだろうけどSQLれんしう。
select * from community_member;
とかして確認。member_id に退会した人のidが残ってる。 member 表内の id として存在しない member_id のレコードは削除する。
select * from community_member where
member_id not in (select id from member);
これで良さそうなら執行。
delete from community_member where
member_id not in (select id from member);
再度 select * from community_member; で確認しておしまい。
だったのだが、C-pで戻ってやったら先頭の select * を delete のママやっちゃって全部消えちゃったョ!(;_;) 幸いまだ2人しかいないコミュニティなので慌てて追加。
describe community_member;
+------------------------+------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------------------+------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| community_id | int(11) | NO | MUL | NULL | |
| member_id | int(11) | NO | MUL | NULL | |
| is_pre | tinyint(1) | NO | | 0 | |
| is_receive_mail_pc | tinyint(1) | NO | | 0 | |
| is_receive_mail_mobile | tinyint(1) | NO | | 0 | |
| created_at | datetime | NO | | NULL | |
| updated_at | datetime | NO | | NULL | |
+------------------------+------------+------+-----+---------+----------------+
コミュニティidが1のやつなので、そこに2人追加した。 「通知をPCで受け取る」は is_receive_mail_pc なのでそいつを1にしとくか。
insert into community_member values (9, 1, 3, 0, 1, 0, now(), now()); insert into community_member values (9, 1, 6, 0, 1, 0, now(), now()); select * from community_member;
ふう。やれやれ。
にしてもM1のときに習ったSQLは全く身に付かなくって、 ものすごく厄介でそれ以来ずっと避けて来た。tym先生ゴメンナサイ。 必要に迫られて「やべーどうしよう!」なときの3時間は、 学生のときに動機もなく習う半年間を上回るのだな。 つまりは教える場合は 必要に迫られる機会を与えることに注力すればいいということで、 それには本気で動いている現場的な機会を創り出すことが重要なのだな。
もっとも3時間といっても、既にSQL以外で色々なところでデータを 自動化処理で使うセンスを培ってからの話だから、そういうのを培うために 楽しく失敗して次を覚えたい動機が生まれる機会を用意しないといかんか。
最初、SQLのサブクエリなんてものは全く存在を知らなかったが、 シェルのバッククォートとか $( ) があるから、SQLにもあるに違いないと 思ってちらっと見てなるほどなわけで、そういう意味ではシェル構文の 学習ってこういう合成関数的な意識が根付くからやっぱり大切。 オブジェクト指向言語でもいいけど。
でもまあ、ある程度分かるようになってもSQLはメンドウクサイ。 自分が設計するものではdatadir形式を貫くかな。