「SQL」の記事 - Crieit

全テーブルの中から対象データが含まれているテーブルと項目を取得

2022-12-19T13:23:20+09:00

--//出力表示
SET SERVEROUT ON;

DECLARE
    --//変数定義
    type cursor_type is ref cursor;
    cur_search cursor_type;
    vCount INTEGER;
    ERR_CODE NUMBER;
    ERR_MSG VARCHAR2(255);

    TYPE objName IS VARRAY(260) OF VARCHAR2(30);

    --//対象データを指定
    tDATE objName := objName('')


BEGIN
    --//テーブルを指定する（全テーブルの中から特定の文字列が含まれるテーブルを指定）
    FOR vRec (SELECT table_name,column_name FROM user_tab_cols WHERE table_name LIKE '' OR table_name = '')

    LOOP
        BEGIN
            --//指定したテーブルの中から対象データを検索
            FOR i IN tDATA.first..tDATA.last LOOP
                OPEN cur_search FOR 'SELECT COUNT(*) AS cnt FROM ' || vRec.column_name || 'LIKE ''%' || tDATA(i) || '%''';
                    FETCH cur_search INTO vCount;
                    IF vCount > 0 THEN
                        --//対象データがあった場合、そのテーブルと項目名、件数を出力する
                        DBMS_OUTPUT.PUT_LINE( tDATA(i) || ':' || vRec.table_name || '.' || vRec.column_name || '　' || vCount || '件あり' );
                    END IF;
                CLOSE cur_search;
            END LOOP;
        EXCEPTION
        --//例外処理
        WHEN OTHERS THEN
            ERR_CODE := SQLCODE;
            ERR_MSG  := SUBSTEB(SQLERRM,1,255);
            DBMS_OUTPUT.PUT_LINE('error:' || ERR_CODE || '　' || ERR_MSG || '　' || vRec.table_name || '.' ||  vRec.column_name );
        END;
    END LOOP;
END;
/

AccessをやりながらSQLもやる。「JOIN」

2021-12-06T07:35:52+09:00

今の仕事がいやだというモチベーションによって、
いまだかつてない熱量でAccessとSQLに本気で取り組んでいる。（大袈裟）

Microsoft Office Specialist Microsoft Accsess 2016 対策テキスト&問題集 (よくわかるマスター)

という本を「2020年5月」にAmazonで購入していたらしい。

途中まで進めていたのだけど、最近、最初からせっせとやり直ししている。

前に作ったテンプレートを発見したが、日付は1年半前(2020年6月)だった。

テーブルの章が終わってクエリに突入した。

それで、この前紹介したYouTubeのおかげで、
AccessでのSQLの表示の仕方がわかったので、表示してみたら、「INNER JOIN」と書いてある。

知ってるけど知らない。（見たことあるけど覚えてない）

調べる。

【INNER JOIN, LEFT JOIN , RIGHT JOIN】テーブル結合の挙動をまとめてみた【SQL】

両方ともの表にないと表示されないのがINNER JOIN。

他のもまとめて覚えよう。

Access本の次の課題のSQL文を見たら「INNER JOIN」が何個もあって、気が遠くなった。
自動生成されているからこうなっているのか、それともこんな見た目が複雑な結合を書くのかな。
（どこが区切りなのか分かりづらい）

本の課題自体は、すでに出来上がっているものに一部の操作を加える手順が書いてあるので、
課題だけをやるならなんの支障もないのだが。

まあ（Accessは）クエリが山場だ・・・。

でもさらっとやって、あとで見直そう。
繰り返した方が記憶に定着するだろうし、進んでる気分になれるし。

それにこんなところでてこずっている場合ではない。
総合演習問題が解けないと意味がない。

パソコンを開けない時は本を開いている。
スッキリわかるSQL入門第2版ドリル222問付き! (スッキリわかる入門シリーズ) 中山清喬

6章の「集計とグループ化」まで読んだ。JOINは8章に出てくるらしい。

この本も前に見ているはずだけど、すっきりさっぱり記憶にない。

がんばる。

SQLの勉強「SQL攻略」「SQL入門」

2021-12-04T06:58:24+09:00

SQL攻略

「SQL攻略」
http://sql.main.jp/

ちょっと古いサイトで、httpだけど。。

WEBサイト内でサクサク動かせるのはいい。

SQL入門

スッキリわかる SQL 入門ドリル215問付き! (スッキリシリーズ) 中山清喬

前にこの本を買って、途中まで読んだ。
この本の問題はWEBサイトでできます！って書いてあって
確かにできるのだけど

作りが・・・すごく使いづらい。
動くけど、使いづらい。もうちょっとなんとかならなかったのかな。

普通、WEBサイトで入力しながら学習できます！って
すごく勉強しやすいものだと思うのだけど。

だったら、テーブルデータだけをダウンロードできるとか、の方が良かった。

データを手入力でポチポチ入れるの大変だから、
selectを使いたいときに、DB作ってテーブル作ってデータ入れてたらちょっと大変すぎる。

まあ「DB作ってテーブル作ってデータ入れる」のの練習にはなるだろうけど・・・。

会社にこの本が置いてあった。
でもこの本じゃなくて別の本が見たかったなー。

SQLってもっと複雑なイメージなんだけど、
もしかしてそうでもないのかな？

SQL Server

SQL Server 2008の教科書―基礎から実践まで学べる松本美穂

前に(2018年頃？)この本中古で買ってやってみてた。

役に立っているかどうかは、
もう内容を忘れたので分からない。

まとめ

本はたくさん（？）出てるので、いくつか図書館で予約して借りる予定。
借りてみて良さそうだったら、買うこともあるかもしれない。
重複している箇所がたくさんありそうだけど、ある程度までは練習と思ってやってみるのがいいかも。

Postgres SQL基本の書き方

2021-02-08T15:25:27+09:00

PostgreSQLにおける主なデータ型

文字型

コマンド	型	意味
char(n)	文字型	n文字分の長さの固定長文字列
varchar(n)	文字型	最大n文字の長さの可変長文字列
text	文字型	文字数に上限がない可変長文字列
smallint	数値型	-32768~32768の整数
integer	数値型	-2147483648~2147483647の整数
real	数値型	浮動小数点型で6桁の精度
double precision	数値型	浮動小数点型で15桁の精度
serial	数値型	1~2147483647の自動増分整数
date	日付／時刻型	年月日
timestamp	日付／時刻型	年月日時分秒

コマンドプロンプトから入る

psql –U postgres

[CUI操作]

データベース一覧を表示

¥l

アルファベットのエル

データベース作成

CREATE DATABASE データベース名;

データベースへ接続する

¥c データベース名

キャンセル

¥r

テーブルの定義の確認

¥d テーブル名

テーブルが存在することを確認

¥dt

CSVファイルをインポートする

¥copy テーブル名 from ’ファイルパス’ [各種オプション]

ファイルパスの後ろにはオプションとして「csv」と「header」を入力。
これはインポートするのがCSVファイルで、そのファイルにはヘッダー行があることを意味

Access　SQL書き方

2021-02-02T12:49:00+09:00

用語

テーブル：シートのこと
カラム：列
レコード：テーブルとカラムが、データが保管される場所のこと
フィールド：レコードを構成する１つ１つの要素のこと（Excelでいうセルに該当）

画面で定義するデータ型とSQL文のデータ型の対比表

設定するデータ型	SQL文で使用するデータ型	意味
短いテキスト	TEXT(n), VARCHAR(n)	文字列や計算対象としない数字。フィールドサイズにて255文字まで格納可能な文字数を設定できる
長いテキスト	LONGTEXT, LONGCHAR	256文字以上になる長い文字列
数値型(長整数型)	INTEGER,INT,LONG	-2,147,483,648〜2,147,483,647の整数データ
数値型(整数型)	SMALLINT,SHORT	-32,768〜32,767の整数データ
数値型(単精度浮動小数点)	SINGLE,REAL	-3.40E+38〜3.40E+38の浮動小数点データ
数値型(倍精度浮動小数点)	DOUBLE,FLOAT	-1.79E+308〜1.79E+308の浮動小数点データ
日付、時刻	DATETIME	日付や時刻のデータ
オートナンバー型	AUTOINCREMENT	レコードを新規追加する度に固有の番号が自動入力されるデータ

数値型とは…数量や重量など計算対象となる数字。数値型は、フィールドサイズと組み合わせることで実質、それぞれ別のデータ型になります。

テーブルを作成するSQL文

CREATE TABLE テーブル名 (フィールド名 データ型,…);

テーブルの削除

DROP TABLE テーブル名;

主キー設定

CREATE TABLE テーブル名 (フィールド名 データ型 PRIMARY KEY,…);

※主キーにしたいフィールドの、データ型を指定した後ろに、半角スペースを入れて、「PRIMARY KEY」と入れる

複数の主キーを設定

CONSTRAINT 主キー名 PRIMARY KEY (フィールド名1,フィールド名2,…)

データを追加

INSERT INTO テーブル名 (フィールド名1,フィールド名2,…)
VALUES(追加する値1,追加する値2,…);

文字列を値として入力する際は、「’(シングルクォーテーション)」で囲みます

追加したレコードを参照（検索）する

「WHERE」句の後も「抽出条件」とだけ書きましたが、ここも基本的には
フィールド名を使って「フィールド名=○○」というような指定をします
複数の条件を入れる際は「AND」や「OR」を使用。

データを更新する

UPDATE テーブル名 SET フィールド名=更新する値
WHERE 抽出条件;

VBAの変数と似ている部分は、例えばAとBの文字列を
結合した値でCフィールドを更新する場合、「SET C=A & B」とする

並べ替え

SELECT フィールド名 FROM テーブル名
WHERE 抽出条件
ORDER BY フィールド名 [ASC|DESC];

フィールド名の後ろに何も書かないか「ASC」と入れると「昇順」に、「DESC」と入れると「降順」になります

集計

１．フィールド名を指定せず「*」

SELECT COUNT(*)
FROM テーブル名;

２．COUNT関数の引数で、フィールド名を指定する

SELECT COUNT(フィールド名)
FROM テーブル名;

SELECT文などで、抽出結果が式の結果であったり、複数のテーブルを結合する際のテーブル名などには、別名（エイリアス名）を付けることが出来る

[別名をつけたい式やフィールド名、またはテーブル名] AS 別名

「AS」と書いて、「別名」を入れる

集計する(GROUP)

SELECT グループ化するフィールド名,集計式
FROM テーブル名 
WHERE　抽出条件 
GROUP BY グループ化するフィールド名;

「GROUP BY」の後ろにグループ化するフィールド名を指定するのですが、同じものを、必ずSELECTの後ろにも書かないといけません。
「GROUP BY」で集計した結果を抽出条件としたい場合は「HAVING」
※この場合は「WHERE」句で指定するわけではない

今あるテーブルから新しいテーブルを作る

SELECT フィールド名 INTO 新しいテーブル名
FROM テーブル名
WHERE 抽出条件;

「FROM」の前に「INTO 新しいテーブル名」と入れるだけ

※他のデータベースでは似たような機能を使う場合、「CREATE VIEW」を使ってビューと呼ばれるものを作成する必要がある

抽出した結果を既存のテーブルに追加

「INSERT INTO」ステートメントの「VALUES」句の代わりに「SELECT」ステートメントを繋げて指定する

INSERT INTO 追加先テーブル名
SELECT フィールド名（式、リテラル値）
FROM 追加元テーブル名
WHERE 抽出条件;

※SELECTの抽出結果の値が、必ず追加先テーブルのフィールドの数とそのデータ型に、合致しないといけない

条件式を使って抽出(IIF関数/あんま使わん)

この関数はSQLの標準ではなく、使えるのは、Microsoft社製のデータベースのみ（Accessの他にSQLSeverがある）となります。

IIF(評価する式,[真の場合の値または式],[偽の場合の値または式])

年齢を計算(あんま使わん)

最初の引数には「’yyyy’」「生年月日」フィールドを使って、「2020年4月1日」を基準に何歳かを出しますので、次の引数には「生年月日」を、最後の引数には「#2020/4/1#」を
入れています。

DATEDIFF(計算に使用する時間単位,日付1,日付2)

内部結合

SELECT 取得フィールド名
FROM 結合元テーブル名
INNER JOIN 結合先テーブル名
ON 結合元テーブルの結合キー = 結合先テーブルの結合キー;

それぞれのテーブルで、結合するキーが一致するレコードのみ抽出する結合方法

左外部結合

SELECT 取得フィールド名
FROM 結合元テーブル名
LEFT JOIN 結合先テーブル名
ON 結合元テーブルの結合キー = 結合先テーブルの結合キー;

結合元のテーブルのレコード全件取得に対し、結合先のテーブルは結合キーが合致するレコードのみ結合する方法です。結合キーが合致しないレコードには「NULL」が入る

右外部結合

SELECT 取得フィールド名
FROM 結合先テーブル名
RIGHT JOIN 結合元テーブル名 
 ON 結合元テーブルの結合キー = 結合先テーブルの結合キー;

左外部結合が反転した結合方法

覚えておきたいSQL文

2021-02-01T17:27:32+09:00

前書き

この項目では自分が覚えておきたいと思ったSQL文と用法を記載しておく。
Access VBAで使うことを想定して書いている。

CREATE TABLE

CREATE TABLE テーブル名 (フィールド名 データ型,…) CONSTRAINT 主キー名 PRIMARY KEY (フィールド名1,フィールド名2,…);

テーブルを作成すコマンド。

例
　CREATE TABLE 社員マスタ
(
社員番号 TEXT(3),
社員名 TEXT(8),
CONSTRAINT 社員マスタPK PRIMARY KEY (社員番号)
);

データ型の設定

データ型名	SQLで使用するデータ型
短めのテキスト	TEXT(n),VARCHER (n)
長いテキスト	LONGTEXT,LONGCHR
数値型（長整数型）	INTEGER,INT,LONG
数値型（整数型）	SMLLINT,SHORT
数値型（単精度浮動小数点）	SINGLE,REAL
数値型（倍制度浮動小数点）	DOUBLE,FLOAT
日付、時刻	DATETIME
オートナンバ型	AUTOINCREMENT

INSERT INTO

INSERT INTO テーブル名 (フィールド名1,フィールド名2,…) VALUES(追加する値1,追加する値2,…);

作成したテーブルにデータを追加する。
* 例
INSERT INTO 社員マスタ(社員番号,社員名) VALUES(’S01’,'立花　太郎');

UPDATE

UPDATE テーブル名 SET フィールド名=更新する値 WHERE 抽出条件;

データの更新を行う。

例
UPDATE SET 社員名＝'田中　太郎' WHERE 社員番号＝’S01’;

DELET

 DELETE * FROM テーブル名 WHERE 抽出条件;

データの削除を行う。

例
DELET * FRPM 社員マスタ WHERE 社員番号='S01';

ORDER BY

SELECT フィールド名 FROM テーブル名 WHERE 抽出条件 ORDER BY フィールド名 [ASC|DESC];

データを昇順か降順かで、並び順を変える。
* 例
SELECT * FROM 社員マスタ WHERE 年齢 >= 10 ODER BY 年齢;

COUNT

SELECT COUNT(*) FROM テーブル名;

宣言したテーブルの件数や、フィールドの件数を出力する。
* 例
SELECT COUNT(*) FROM 社員マスタ;

AS

SELECT COUNT(*) AS 別名  FROM テーブル名;

項目を別名にしたい際に使う。
* 例
SELECT COUNT(*) AS 件数 FROM 社員マスタ;

PostgreSQL：とにかく簡単にトレンドやホットランキングを出したい

2019-12-08T18:59:22+09:00

CGMなどを作っていると、現在人気の投稿をトレンドとしてランキング表示したいときがある
これをSQLだけで実装する
パフォーマンスも何も考えていないしテーブル構成にも依存しているし、さらには手動で調整するマジックナンバーさえある
だが、簡単なのでとりあえずそれっぽい機能を付けたいとなったときに役立つかもしれない

環境

PostgreSQL

テーブル構成1

ランク付けの対象として投稿を表すPOSTテーブルがあり、閲覧数を表すVIEWテーブルと一対多のリレーションになっているとする（閲覧されるたびにVIEWテーブルのレコードが増えるパターン）

また、各テーブルには作成日時created_atと更新日時updated_atがあるとする

SQL

SELECT "post".*, (COUNT(DISTINCT view))  as rank_point
FROM "post"
LEFT OUTER JOIN "view" ON "view"."post_id" = "post"."id" AND "view"."created_at" >= now() - interval '1 hour'
GROUP BY post.id
ORDER BY rank_point DESC;

LEFT OUTER JOINで結合する時にVIEWテーブルの条件を調整している
"view"."created_at" >= now() - interval '1 hour'は現在時刻から1時間前までの間に作成されたVIEWのレコードのみ結合するという条件で、これをカウントしてrank_pointとし、post.idでグルーピングしたものを降順に並べれば1時間のうちで閲覧が多い投稿が順に並ぶはずである
interval '1 hour'の部分は好きなように調整できる

テーブル構成2

他の指標を使いたくなったらいくらでも追加できる
例えば投稿には一対多でコメントがあって、コメントの多さでも人気なことを表したいとする

SQL

SELECT "post".*, ( (COUNT(DISTINCT view) * 10) + (COUNT(DISTINCT comment) * 1000 ) ) / 2  as rank_point
FROM "post"
LEFT OUTER JOIN "view" ON "view"."post_id" = "post"."id" AND "view"."created_at" >= now() - interval '1 hour'
LEFT OUTER JOIN "comment" ON "comment"."post_id" = "post"."id" AND "comment"."created_at" >= now() - interval '1 hour'
GROUP BY post.id
ORDER BY rank_point DESC;

説明

VIEWに加えてCOMMENTも同じように結合する
あとは適当に掛け算して桁を合わせてから指標の数で割ったものをrank_pointとするだけだ
桁を合わせるとは書いたが、重視したい指標に多めの数値を掛けるなりすれば重み付けもできる

蛇足

最初はちゃんと移動平均を出そうと思ってWindow関数とか調べたが、複数テーブルが絡むと面倒な記述になりそうでやめてしまった

参考

9.9. 日付/時刻関数と演算子

MySQLの負荷を軽くするための方法や設計の例を色々書いてみる

2019-05-13T21:16:38+09:00

昔１年ほどアクセスが多く下手なことをするとすぐ重くなってしまうソーシャルゲームの開発＆運用を行ったことがあります。MySQLの運用方法についてはそこで色々と叩きこまれたためその後の開発にも役立っていますが、せっかくですので色々と思いつく軽量化の方法を色々と例をあげつつ書いてみたいと思います。

前提

最新のMySQLの挙動を全て正確に把握しているわけではありません。そのため「いや、ここはこういうやり方でも大丈夫なはずだけど…」という話も出てくると思います。ただ、とりあえず深く考えたり知ったりしていなくてもできる極端な方法をあげていくため、そのあたりの細かい部分は考慮していません。何かあればコメントで補足していただいたり、別途最新の仕様に基づいたより良い使い方ができる記事などを書いていただけると助かります。

シンプルなSQLしか使わない

基本的に、下記のようなシンプルなSQLのみを使います。

SELECT columns FROM table WHERE column = value ORDER BY order_column

インデックスを効かせる

columnやorder_columnはインデックスが効くものだけを使います。EXPLAINで適宜確認しましょう。

ただしデータが1000以下程度のテーブルであればそもそもインデックスを使ってくれなかったりするため、適当で良いです。ただ後のちデータが増える可能性があるテーブルはその時に調整などが必要になると面倒ですので、予め考えておいて作り直しがなるべく必要ではなくなるように作っておいたほうが良いとは思います。

便利な機能は使わない

下記のものは基本的には使いません。

OR
JOIN
UNION
サブクエリ
関数

等々。こういうものを使っていくとインデックスが効かなくなったりする場合がありますし、検索も各データ毎に更に検索を行う、というN+1問題的なものが発生し始めるので負荷が発生する原因となる可能性がでてきます。

でも使えないとこまるんだけど…、という場合が出てくると思いますが、それは設計でカバーすることで実現していきます。引き続き色々と例をあげてみます。

わざわざデータを冗長にする

例えばフレンドについて考えてみます。Twitterのようなフォロー、フォロワーのような双方で独立した関係であれば問題はありませんが、「フレンド」というお互いのつながりのみで成り立つ場合の話です。たとえば下記のようなfriendsテーブルがあるとします。

カラム	型
user_id	int
friend_id	int

これでAさんとBさんをフレンドとして繋げる場合、user_idにAさんのID、friend_idにBさんのIDを入れるとします。この場合、「Aさんのフレンド一覧」を検索する場合、下記のSQLが必要になります。

SELECT * FROM friends WHERE user_id = AさんのID OR friend_id = AさんのID

ORを使っているのでインデックスも効かなくなりますし悲惨です。Twitterのフォロー・フォロワーの関係と同じように、フレンドになった場合は１レコードではなく双方用の２レコードを入れることで、シンプルなSELECT文だけでフレンド一覧を取得できるようになります。

SELECT * FROM friends WHERE user_id = AさんのID

わざわざテーブルの構造を冗長にする

例えば記事にタグを付けられるように下記のようなbelongsToMany的な構成の３つのテーブルが存在するとします。

posts - post_tag - tags

post_tagはこんな感じです。

カラム	型
post_id	int
tag_id	int

ここで、「あるタグがついている記事を検索する」という機能をつけたい場合、これは簡単です。

SELECT * FROM post_tag WHERE tag_id = 検索したいタグID

これでpost_idが分かるので、表示する10件程度だけpostsを取得すれば完了です。（LaravelのEager Loadingだとこれも勝手にやってくれます）

では「あるユーザーが記事につけた全てのタグを取得」となるとどうでしょう。下記のSQLでしょうか？

SELECT DISTINCT
    post_tag.tag_id
FROM
    post_tag
    LEFT JOIN
        posts
    ON  posts.id = post_tag.post_id
WHERE
    posts.user_id = ユーザーID

個人的にリレーションしたテーブルだけでWHEREを作ったSQLは危険だと思っています。インデックスも効きませんし、内部的には全データの関連データを取得しないと絞り込みができません。

この場合、post_idとtag_idしかないpost_tagにuser_idも加え、保存時にuser_idも入れておくことでシンプルなSQLにすることができます。

カラム	型
post_id	int
tag_id	int
user_id	int

SELECT * FROM post_tag WHERE user_id = ユーザーID

SQLを分けてシンプルにする

上記の話と少しかぶりますが、例えばユーザー名で記事を検索したい場合。JOINして検索するのではなく、まずユーザー名がヒットするユーザーのIDを先に取得しておきます。次にそれを使ってuser_id IN (既に取得したユーザーID一覧)で記事の検索は行います。

クエリ数は増えますがJOIN先の検索が不要になるため状況によっては大幅な軽量化ができる場合があります。

表示時には複雑な検索をしない

どうしても複雑なSQLでランキング作成や集計処理を行わなければならない場合があると思います。この場合、表示する際に集計するのではなく、予め定期的なバッチ処理で集計してキャッシュに保存しておき、表示する際にはそれを表示するだけにすることで負荷をなくすことができます。

生SQLを見る

ORMを使っているとよく分からず作ってしまう場合もありますので、生SQLを時々見るようにしましょう。大体のフレームワークが開発時にはログを垂れ流してくれていると思います。

Laravel等はDebugbarがあり画面上でログを見れたりします。SQLの件数等も表示されていたりするため、誤ってループ内で更にSQLを実行してしまっている時なども気づきやすいです。

特にリレーションのSQL等はフレームワークによって異なっていたりするため、確認せずに進めているととんでもないSQLが発行されていることなどもあります。ちょこちょこ確認し、気になったものはEXPLAINでチェックするようにしましょう。

やっても問題ないことはある

色々書きましたが、実際にはやっても問題ないことはあると思います。バージョンによって可能なことは変わっていくでしょうし、MySQL以外だと最適化されているものもると思います。ただ、「あれ、どうだったっけ？」みたいなパターンが増えてくると思うため、まずは思考停止でなるべく怪しいことはしないようにし、どうしても必要な場合はちゃんと調査＆検証を行って問題ないことがはっきりしたらやっていくと良いと思います。

まとめ

色々と書きましたがそんなに多くはなかったですね…。

何にしろこのように、手法や設計を変えることで負荷を与えなくても同じ動作を行えることというのはいくつもありますので、負荷的にあやしい処理をつくってしまいそうな場合にはまず設計を見直して軽量化できないかを考えてみると良いと思います。

ちいさなシステムの場合はさほど問題ないかもしれませんが、大規模な場合はそれだけでサーバーを数台減らせて何十万円と節約できたのに、という場合も多々あると思います。メリットが「ほんのちょっと」というレベルではない場合もありますので、その都度色々と考えてみてください。

この他にも色々と改善のアイデアはその都度出てくると思いますので、とにかくその都度DBちゃんの気持ちになって、どれだけたくさんのデータを見なきゃいけないかをその都度考えてみましょう。DBちゃんは現実に存在するのです…。無理に酷使してはいけません…。

まとめ２

もっと色々知りたい方は、大規模ゲームについてや、大規模サービスについてのDB運用方法について書かれたスライドが数多く存在します。僕はもう見つけられないのですが是非探してみてください。単にクエリやスキーマの調整だけでなく、DB自体の分け方や様々なテクニックが色々なところで紹介されています。

野球のデータを用いて選手間の「類似度」を計算する

2019-04-21T19:39:23+09:00

背景

今回は統計の話に近くなってしまうのですが、選手を傾向に応じてグループ化できると面白いなーと思っていて、「野球　似ている　選手」などでググってみると、Baseball LABのコラムを見つけました。
コラム：「近い」選手とは？

類似度の計算について

現在データを集めている野球リーグでは、選手によって打席数の差がかなりあり、グラフを描いたときの二点間の距離(ユークリッド距離)の算出に打席数の偏りが反映されてしまうため、x,y軸に割合を採用することにしました。

ユークリッド距離とは

ユークリッド距離 - wikipedia
要は2点間の距離です。今回は二次元を扱うので、皆さんご存知の三平方の定理を使います。

x,y軸に採用するもの

どのような指標を採用するかによって、類似度の現れ方が異なるので、
事前にChart.jsなどでグラフを書いていくつか検討した結果です。

打者の場合

長打率(SLG)：塁打の合計数を打席数で割った指標。
打数 / 三振比率 (At Bats per Strikeout : 三振のしにくさ)

MySQLでのユークリッド距離の計算

SELECT
全体の成績を計算したものからselectして、ある選手のAB/Kと長打率の数値を渡して類似度が近い順に5つのレコードを取り出します。
WHERE
選手自身が類似度0として取れてしまうのでwhere句で除外します。
代表的な選手を類似度の候補として挙げるために条件を42打席以上としています。

select 
    name,
    player_id,
    tpa,
    not_strike_out,
    SLG,
    SQRT(POW(?-not_strike_out,2)+POW(?-SLG,2)) as distance
 from(
SELECT
    player_id,
    name,
    p.team_id as teamId,
    team_name,
  CASE
    WHEN (sum(hit)/sum(at_bats)) is null THEN 0
    WHEN (sum(hit)/sum(at_bats)) is not null THEN (sum(hit)/sum(at_bats))
  END as average,
  CASE
    WHEN ((sum(hit)+sum(twobase)*1+sum(homerun)*2)/sum(at_bats)) is null THEN 0
    WHEN ((sum(hit)+sum(twobase)*1+sum(homerun)*2)/sum(at_bats)) is not null THEN ((sum(hit)+sum(twobase)*1+sum(homerun)*2)/sum(at_bats))
  END as SLG,
  CASE
    WHEN ((sum(hit)+sum(four_ball))/sum(tpa))+((sum(hit)+sum(twobase)*1+sum(homerun)*2)/sum(at_bats)) is null THEN 0
    WHEN ((sum(hit)+sum(four_ball))/sum(tpa))+((sum(hit)+sum(twobase)*1+sum(homerun)*2)/sum(at_bats)) is not null THEN ((sum(hit)+sum(four_ball))/sum(tpa))+((sum(hit)+sum(twobase)*1+sum(homerun)*2)/sum(at_bats))
  END as OPS,
    (sum(hit)+sum(four_ball))/sum(tpa) as OBP,
    ((((sum(hit)+sum(twobase)*1+sum(homerun)*2)+0.26*sum(four_ball)-0.03*sum(strike_out)+3*sum(tpa))*(sum(hit)+sum(four_ball)+2.4*sum(tpa)))/(9*sum(tpa))-0.9*sum(tpa))*27/(sum(at_bats)-sum(hit)) as RC27,
    CASE
    WHEN sum(at_bats)/sum(strike_out) is null THEN 0
    WHEN sum(at_bats)/sum(strike_out) is not null THEN sum(at_bats)/sum(strike_out)
  END as not_strike_out,
  CASE
    WHEN sum(four_ball)/sum(strike_out) is null THEN 0
    WHEN sum(four_ball)/sum(strike_out) is not null THEN sum(four_ball)/sum(strike_out)
  END as bbk,

  CASE
    WHEN sum(at_bats)/sum(homerun) is null THEN 0
    WHEN sum(at_bats)/sum(homerun) is not null THEN sum(at_bats)/sum(homerun)
  END as avg_homerun,
  CASE
    WHEN sum(rbi)/sum(at_bats) is null THEN 0
    WHEN sum(rbi)/sum(at_bats) is not null THEN sum(rbi)/sum(at_bats)
  END as avgRbi,
  sum(tpa) as tpa,
    sum(at_bats) as at_bats,
    sum(hit) as hit,
    sum(rbi) as rbi,
    sum(four_ball) as four_ball,
    sum(strike_out) as strike_out,
    sum(twobase) as twobase,
    sum(homerun) as homerun
 FROM batting_sum b
  INNER JOIN game g on b.game_id=g.game_id
  INNER JOIN player p on b.player_id=p.id
  INNER JOIN team t on t.team_id=p.team_id
 group by player_id)p
where tpa>=42 and player_id <> ?
order by distance asc
limit 5

投手の場合

WHIP(Walks plus Hits per Inning Pitched)：与四球・被安打数合計の合計を投球回数で割ったもの。
奪三振率：奪三振率＝奪三振数× 5 ÷投球回

MySQLでのユークリッド距離の計算

select 
player_id,
name,
WHIP,
strike_avg,
inning,
SQRT(POW(?-WHIP,2)+POW(?-strike_avg,2)) as distance
 from (

SELECT
  p.player_id,
  name,
  pl.team_id as teamId,
  team_name,
  sum(runs)/sum(inning)*5 as era,
  (sum(hit)+sum(four_ball))/sum(inning) as WHIP,
  sum(four_ball)/sum(inning)*5 as BB5,
  sum(strike_out)/sum(inning)*5 as strike_avg,
  sum(inning) as inning,
  sum(pa) as pa,
  sum(hit) as hit,
  sum(homerun) as homerun,
  sum(four_ball) as four_ball,
  sum(strike_out) as strike_out,
  sum(runs) as runs,
  sum(complete) as complete,
  sum(shutout) as shutout,
  sum(win) as win,
  sum(lose) as lose,
  sum(save) as save,
  p3.run_support
 FROM
 pitching p
  inner join game g on g.game_id=p.game_id
  inner join player pl on p.player_id=pl.id
  inner join team t on t.team_id=pl.team_id
  left outer join(
    SELECT
        p.player_id as player_id,
        sum(p2.runs)/sum(p2.inning)*5 as run_support
    FROM pitching p
    inner join game g
    on p.game_id=g.game_id
    inner join pitching p2
    on p.game_id=p2.game_id and p.myteam_id!=p2.myteam_id
    group by player_id)p3
    on p3.player_id=p.PLAYER_ID
group by player_id)p
where player_id<>? and inning >= 18
order by distance asc
limit 5

実装結果

野球リーグスコア管理システムの方に改修内容を反映しています。

選手例1

この選手の場合は投球は軟投派の投手との類似度が高いことが示せています。
軟投派の場合は奪三振率が低めになる傾向があります。
打者としてはパワーヒッターで三振のしにくい選手が類似選手として挙がっています。

選手例2

この選手の場合は速球派で長打力のある選手が類似度が高いことを示しています。

SQLでNULLを0として出力する方法

2019-04-02T18:05:06+09:00

MySQLで外部結合したときに、COUNT()の結果が0件だとNULL値が返却されてしまったため、NULLを0として表示する関数を調べました。
ついでに他のDBについても書きました。

関数

IFNULL (a, 0)
MySQL、SQLite

COALESCE (a, 0)
MySQL、SQLite、PostgreSQL、Oracle

NVL (a, 0)
Oracle

ISNULL (a, 0)
SQL Server

使い方

第1引数（この場合カラムa）がNULLだった場合、関数は第2引数（この場合は0）を返します。
第1引数がNULLでなければ、関数はそのまま第1引数を返します。

これらは同じような使い方ができますが、COALESCE()だけ仕様が異なり、引数を無限に設定することができます。
COALESCE()は第1引数から順に「その値がNULLかどうか」を判定し、NULLであれば次の引数へ、NULLでなければその値を返却します。
全ての引数がNULLだった場合は、諦めてNULLを返却します。

SQLデータベースの照合順序の変更

2019-03-10T18:30:03+09:00

USE master;
GO
ALTER DATABASE MyOptionsTest
COLLATE** French_CI_AS **;
GO

--Verify the collation setting.
SELECT name, collation_name
FROM sys.databases
WHERE name = N'MyOptionsTest';
GO

開発時はSQLのログを見よう

2018-11-19T22:22:08+09:00

最近はSQLを利用したアプリケーションを開発する際、ほとんどORMを使うのが当たり前になってきていると思います。しかし実際に実行されるクエリを確認しないと大変なことになることもあるため、開発時のログをある程度は見ながら進めた方が良いと思います。

実行したSQLを見る方法

例えばPHPのフレームワークの場合、LaravelであればDebugbar、CakePHPであればDebugKitを導入することで、ページを開いた際に実行されたSQLの一覧を見たりすることができます。

その他の言語やフレームワーク、例えばRuby on RailsやPhoenix等は、開発サーバーを実行している際にSQLの履歴が流れてくるためそれによって確認することができます。

実際に何を見たら良いのか

基本的に見たほうが良いところというのは、重いSQLではないかと、SQLの実行回数あたりになると思います。

普通のシンプルなSQLであればだいだい問題ないとは思いますが、JOINしていたりサブクエリを含んでいたり関数を使っていたりする場合、そのSQLのEXPLAINで確認してちゃんとインデックスが効いているかなどを見たほうが良いです。ただ、このあたりはスキーマを検討する際にだいたい考えられていたりすることもあるので、大丈夫なことも多いかもしれません。

もう一つ問題となるのが、実行回数です。以前僕が既存のプロジェクトに途中から参加したことがあったのですが、一ページ内で3000以上のクエリを実行しているページがいくつもありました。たしかカレンダーとか、データ一覧のそれぞれのデータに対してループを行い、更に取得したデータに対してもループしてSELECTを実行する、みたいな感じでそれくらいになってしまっていたと思います。

なんでこんな事になっていたのかと言うと、それはLaravelのプロジェクトだったのですが、結局Debugbarを入れていなかったためクエリの実行回数が可視化されておらず、作成した本人も全く気づいていなかったような状態でした。後で僕がDebugbarを入れたため、そのページを触った時に気づきました。

この場合の解決法としては、ループの中でSELECTを実行せず、最初に1回必要なデータを全部取得しておき、ループの中ではそれを参照するだけにする、という形にすればほとんどSELECTを実行する必要がなくなります。

まとめ

今もしSQLを利用しているプロジェクトで実行しているSQLを全く見ていない、という場合、ちょろっと見てみると良いと思います。

特に炎上中のプロジェクトの場合、誰もそのあたり考える余裕もなく適当に作られている場合があるため、怖いもの見たさで可視化してみるとよいかもしれませんよ…。

LaravelのModelからSQLを直接実行する方法

2018-10-04T14:04:32+09:00

LaravelでSQLを直接実行する方法というのは、一般的には下記のようにDBのFacadeを使用する方法になる。

DB::statement($query);

Laravelだと上記で問題ないのだが、EloquentはLaravelでなくても使用できるので、プロジェクトに個別にEloquentを入れている場合はDBファザードが無いため上記が実行できない。

その場合、モデル自体からDBファザードと同じものを取得する方法があるためそれで同じ様にしてSQLを実行することができる。

まず適当にモデルのインスタンスを作成する。

$user = new User;

あとは同様。

$user->getConnection()->statement($query);