面白い関数もあったよ～♪
MySQL：12.5 String Functions
文字列処理関数。
第１引数：対象文字列
第２引数：検索文字列
第３引数：置換文字列
第１引数の対象文字列には、もちろん直接文字列を指定してもいいんだけど
要はデータを扱いたいので、そこにフィールド名を指定する。
フィールド名の場合は、”” は無し。
いわゆる CASE 文。
こんなこともできるなんてね～。
MySQL：13.6.5.1 CASE Syntax
THEN の後ろの値が戻ってくる。
散らばった値を集約して表示できる。
80点を超えた人は合格。
60点を超えた人は再テスト。
それ以外の人は不合格。
散らばった値を集約できる。
ただし、SELECT にも同内容の指定をすること。
豪快に GROUP BY句にも SELECT句の CASE式をコピーしてやるのがポイントです。
単純に「GROUP BY pre_name」と変換前の列を指定すると、
正しい結果が得られませんので注意してください。ミックのページ：CASE式のススメ
任意のソート順を設定できる。
CASE式は CHECK制約と非常に相性が良いのです。
実際に CASE式を使う局面の半分は CHECK制約の中ではないかと思うほどです。ミックのページ：CASE式のススメ
と、あるけど、まだ理解できていない。
ミックのページ：CASE式のススメ 参照。
DBOnline：カラムの値に応じて異なる結果を返す条件式の記述
サンプルコードによるPerl入門：SQLのhaving句はcase式で書くと直感的に記述できる（2011-04-13）
DN-Web64：MySQL : CASE文で複雑な条件を指定
→簡潔で読みやすい。SELECT, GROUP BY, ORDER BY 別にサンプルあり
ミックのページ：CASE式のススメ
→いつもお世話になっております。相変わらずの詳細な解説をありがとうございます。
データの全削除。
当該テーブルにリレーションを貼ってあると下記のようなエラーが出る。
こういうときは、リレーションに対するチェック機能を一旦 OFF に。
最近の XAMPP に入っている MySQL は、my.ini をいじらなくても
phpMyAdwmin からデータベースを作成する際に
文字コードを指定することで、文字化けをしなかったので
そのままで利用していたけど、久しぶりに文字化けに遭った。
何もしてない気がするので、多分下記がデフォルト。
インストール 1.7.3
以前、こちらの記事で書いたのが基本。
以前 の通りに my.ini をいじったら、MySQL が起動しなくなった。
MySQL 5.5 から仕様が変更になったらしい。
[mysqld] についてはcyberarchitect：[ERROR] mysql\bin\mysqld.exe: unknown variable ‘default-character-set=utf8′
むｗ １つだけ latin1。
参考サイトにしたがって、global も覗いてみる。
ほー。こちらはちゃんとなっている。
my,ini 設定前の global 値も見ておけばよかった～。
character_set_database だけが値が異なっている原因は・・・
この値はどこを参照しているかというと、create database した時の値です。
だそうです。
あれれ。
データベースを作成した時に、文字コードを設定しそこねたのかしら。
うほ！確かに。。。
直った～♪
問題解決にはあまり関係ないので
記事末に覚え書き用経緯を。
駅データ.jp
こちらのサイトから、全国の駅データをいただいてきた。
配布されているデータは、ちゃんと UTF8 なのだけど
データを追加する都合上、Excel で編集してから DB へ流し込んだ。
データが多く、phpMyAdmin からではタイムアウトになってしまったので
コマンドラインから実行。
すると、途中から文字化けという事態が起こった。
これはこれで不思議。。。
MySQL のコマンドラインからの操作。
私は MySQL を XAMPP から利用しているので
MySQL も XAMPP 内にある。
コマンドプロンプトを開いたら、下記３種の利用方法がある。
これでパスワードの入力を促されるので
パスワードを入力し、認証が通ったら
ツールを利用できるようになる。
プロンプトが上記のようになれば、起動成功。
-p オプション指定の直後にパスワードを記述する。
スペースを開けずに記述する ところがミソ。
SQL 文の最後に ;（セミコロン）を付けること。
なぜって、下記のようにカスケード記述ができるから？
長い SQL 文を分割して入力できる。
というわけで、文末にセミコロンを付けないと、永遠に -> が出てくる。 🙄
| コマンド | エイリアス |
|---|---|
| quit | \q |
レコードのグループ化
MySQL：13.2.9 SELECT 構文
こうすることで、まず (カラム名1) でグループ化され
その後 (カラム名1) の中で (カラム名2) でグループ化され・・・
ということになる。
グループ化されたカラム以外の値はどうなるのか。
| id | amount |
|---|---|
| 101 | 1 |
| 101 | 2 |
| 101 | 3 |
id:101, amount:1 となる。
つまり、先頭行 の値を取ってくる。
但し、ちゃんと指定すれば、期待する値を取ることもできる。
id:101, amount:3 となる。
最小値は MIN( amount )
MySQL：12.19.1 GROUP BY (集約) 関数
最大値、最小値の他には、下記の指定ができる。
合計：SUM( amount ):6
平均：AVG( amount ):2
レコード数：COUNT( amount ):3
私の場合は、当該グループの最初と最後のデータが欲しかったので
最初はノーマルに取得。
最後はサブクエリでテーブルを逆順にソートして取得。
ORDER BY と併用する場合、グループ化された後にソートされる。
つまり！ 無意味 。
他の記事もそうなんだけど、この記事は特に勉強中で自信がないので、内容が間違っている可能性大。 8-X
MySQL：13.2.9.4 UNION Syntax
クエリ結果が同一構成となる２つ以上のクエリ結果を合成する。
JOIN による結合と違って、リレーションしているわけではない。
単に２つ以上のクエリ結果を１つのテーブル上にする。
２つの SELECT がある。
カラム数は同じく 3。
カラム名は異なっていてもよい。→メインの SELECET 文のカラム名が返る。
この項は勉強、実証ともに特に不十分
UNION は、そのまま使うと重複した行は無視されるらしい。
重複した行を拾いたいときは、下記のように ALL をつける。
こうして合成されたクエリ結果に ORDER BY, LIMIT などの注文を付けたい場合は、更にその後ろに続ける。
そして、SELECT 文を（）で括る。
FROM 句にて UNION を利用するときは、エイリアスを付ける。
このとき、UNION SELECT 文にエイリアスを付けてしまわないように注意。
あくまでも FROM 句全体 に（）を付ける。
これはサブクエリのルールだから当然か～。
サブクエリ
まだおぼろげにしか捉えられていないけど、メモ。
MySQL：13.2.10 Subquery Syntax
SQL 文の中に、独立した SQL 文を入れ込む。
例えば、こんな風に書くと、user テーブルで田中さんの id を突き止め
hoge テーブルにある、田中さんの情報だけを取り出すことができる。 😎
サブクエリは（）で括りましょう。
言葉でうまく説明できないので、参考サイト参照。
でも、こういう使い方ができると便利だね～。
本来テーブル名を書くはずの FROM 句。
ここにサブクエリを置くことで、クエリをテーブルとして扱うことができる。
必ずエイリアスをつけましょう。
私は見事にはまりました。 👿
サブクエリ -> エイリアス
クエリ結果を条件に設定することができる。
まだまだこの程度しかわかっていないので
また判明したことが出てきたら追記！
メインクエリとサブクエリに共通のレーブルが登場するタイプ？
MySQL は苦手とするみたい。
Smart：SELECT構文：サブクエリ構文
TECHSCORE：7. サブクエリ
FROM 句に入れるサブクエリではまった。
この SQL 文が通らない。
これが通っていることは確認済みなのに、何でか通らない。
サブクエリにエイリアスがついていなかった。
FROM 句内でサブクエリを使っているサイトを見ていると
どれにもエイリアスがついているので、もしや・・・と思い試してみたらビンゴ。
どこにも使わないから、エイリアスをつけてなかったんだけど
それが原因でした。
負の数の結果を得る SQL が通らなくて難儀した。
あるカラムの値を負の数として取得したくて、下記のような SQL を投げた。
しかし、これが通らない。
これもだめ。
num カラムの属性を unsigned にしていたことにあったようだ。
属性を外したら結果を取得できた。
属性が unsigned だと、演算結果が負の数になるような演算を受け付けてくれないみたい。
テーブルの属性が、クエリにも影響するとは思わなかった。
エイリアスまでつけたのにな～。 😯