PakuReserve(パクレゼルヴ) R&D Laboratory

とあるプログラムで気になったことをメモ。

PCか携帯か判断する関数。
DBに1＝PC、2＝モバイルという風に入っており、1、2の数字は変更できる仕様になっています。
1、2の数字を変更した場合、当然以下のようなプログラムでは正常に動かなくなってしまいます。

DB:
1(変動)=PC(変動)
2(変動)=モバイル(変動)

$typeにDBの1、2が入ってきます。

function getIsMobile($type) {
	$mobile = false;
	switch($type) {
		case 1:
			$mobile = false;
			break;
		case 2:
			$mobile = true;
			break;
		default:
			$mobile = false;
	}
	return $mobile;
}

DB:
1(変動)=PC(固定)=PC(変動)
2(変動)=MOBILE(固定)=モバイル(変動)

$typeにDBのPC(固定)、MOBILE(固定)が入ってきます。

function getIsMobile($type) {
	$mobile = false;
	switch($type) {
		case 'PC':
			$mobile = false;
			break;
		case 'MOBILE':
			$mobile = true;
			break;
		default:
			$mobile = false;
	}
	return $mobile;
}

解決方法としては、1、2の数字が変動しないようにするか、別に固定のIDを振ってあげて、その固定のIDで判別してあげれば、数字が変動しても動作する柔軟なプログラムになると思います。
基本・・ですよね・・（´・(ｪ)・`;）

下音タヌキ PHP, データベース

こんにちわ！かーつんです！！
不定期更新SQLチューニング基礎3発目です。

ん～と、今回は「union (時と場合でminus)」です。

2つのテーブルの集計結果など、同時に取ってきたいとき。
まぁ、方法としては3種類。

１．2回クエリを投げて、PGで加工する。
２．副問い合わせでSQL内で加工する。
３．クエリ的には1回でunionで結果のみがっちゃんこ。

コスト的には、１＜３＜２の順で高くなるって感じでしょうか。
副問い合わせは使い方にも依りますが、mysqlで使うには少々気が咎める時がありますよね。
でも、どうしても2回クエリを投げれない(投げたくない)。ときってあると思うんです。

そんなとき、同じSQLを2回書いて、unionでくっつけて、結果にしてしまう。
こんな事をたまに思いつきます。
ただ、本来のunionの使い方は、結果の合成なので、
同じフィールド名を持つ違うテーブルの値を合算させてしまうのが定石なのですが、
あ　え　て、同じフィールド名をもつ違うテーブルの値に別名つけて別レコードとして、
同時に取得する。

まぁ、どういうことかというと、

SELECT COUNT(hoge) FROM exampleA;
SELECT COUNT(hoge) FROM exampleB;

というのを、

SELECT COUNT(hoge) AS hogeA FROM exampleA;
UNION
SELECT COUNT(hoge) AS hogeB FROM exampleB;

てな具合にかいて、

結果を

hogeA hogeB
100 200

という具合に取得するわけです。
PG内での加工は通常の結果より面倒ですが、
1度に取らなきゃいけないときに、1度で取れるのがメリットです。

なんかまぁ、基礎というより裏技っぽくなっちゃいましたが、
こんな事も出来ますよ。ってくらいで、知ってて損はないはずです。

あと、MySQLでは使えないのですが、
「MINUS」についても同じような使い方をすることが出来るときがあるので、
いろいろ工夫してみてください。

いじょ。かーつんがお送りしました。

かーつん MySQL, データベース

チョコボールです。
あと一か月働けば実務経験1年です。

前回csvファイルの一般的な書式について書きましたが、

その続きとして、DBから引っ張ってきたデータをCSV出力する関数を作ってみました。

例えば

+----+--------+-------+
| id |   name | level |
+----+--------+-------+
|  1 |  quest |    50 |
|  2 | arthur |    45 |
|  3 |  maria |    35 |
+----+--------+-------+

のようなテーブルが有り、これらを全て引っ張ってきてごにょごにょして下記のような配列に格納するとします。

$header(1行目の項目名)
Array
(
	[0] => ID
	[1] => 名前
	[2] => レベル
)

$data(データ部分)
Array
(
	[0] => Array
		(
			[id] => 1
			[name] => quest
			[level] => 50
		)

	[1] => Array
		(
			[id] => 2
			[name] => arthur
			[level] => 45
		)

	[2] => Array
		(
			[id] => 3
			[name] => maria
			[level] => 35
		)
)

これら配列を下記の関数に渡してやります。

downloadCsv($header, $data, 'member');

function downloadCsv($header = array(), $data = array(), $prefix = '')
{
	$ret = '';
	// ヘッダー(1行目の項目名)がある場合
	if(count($header) > 0){
		foreach($header as $val){
			//「"」は「""」に置換してエスケープ
			$tmp[] = str_replace('"', '""', $val);
		}
		$ret .= '"'.implode('","', $tmp).'"'."\r\n";
		unset($tmp);
	}

	foreach($data as $val){
		foreach($val as $vval){
			$tmp[] = str_replace('"', '""', $vval);
		}
		$ret .= '"'.implode('","', $tmp).'"'."\r\n";
		unset($tmp);
	}

	// 文字コードを変換
	$ret = mb_convert_encoding($ret, 'SJIS', 'UTF8');

	// 出力する際のファイル名
	$file_name = $prefix.date('Ymd').'.csv';

	// HTTPヘッダ出力
	Header("Content-Disposition: attachment; filename=${file_name}");
	Header("Content-Type: application/octet-stream; name=${file_name}");
	Header("Cache-Control: ");
	Header("Pragma: ");

	// データを出力
	echo $ret;
	exit;
}

member20081031.csvみたいな感じでDLできると思います。

もちろん、ソース内コメントの「文字コードを変換」部分は内部文字コードに合わせて変更しないとCSVが文字化けしてしまいます。
上記はUTF-8の場合です。

あと、バッファーに何か入ってる場合(デバッグ出力文字等)、その文字もCSVに出力されてしまうので、一番最初の行に

ob_end_clean();

を追加して出力のバッファリングをオフにすると良いです。

一度軽くハマったんですが “\r\n” は ‘\r\n’ じゃ駄目です。
文字列として認識してしまいますので。
ダブルクォートで囲んであげましょう。

MoriMoriMoriMori MySQL, PHP, データベース

こんばんわ。かーつんです。

SQL負荷って、考えたことありますか？

条件などにもよりますが、
SELECT、INSERT、DELETE、UPDATE順に徐々に重くなります。
理由は簡単。

SELECT＝検索
INSERT＝挿入＋インデックスレコード追加
DELETE＝検索＋削除＋インデックスレコード更新
UPDATE＝検索＋更新＋インデックスレコード更新

と、処理が増えるからです。
例えば、UPDATEを１００回投げるなら、
TRUNCATE＋INSERTの方が早い事もあります。
要するに更新が一番重く、検索が一番早いわけですね。

で、よくあると思いますが、
あればUPDATEかけて、なければINSERTというのを
SELECT＋UPDATE＋INSERTの組み合わせでやってる方が多いと思います。
そんなときは、迷わずREPLACEを使いましょう。
REPLACEは検索＋[更新｜挿入]＋インデックス[更新｜挿入]です。

上の例だと、
SELECT＋（UPDATE or INSERT）＝検索＋[（検索＋更新）｜挿入]
REPLACE＝検索＋[更新｜挿入]

どちらが早いか一目瞭然ですよね。
検索一回分REPLACEの方が早いです。
もちろん条件的に無理。ということもありますが、
使えるときは使っちゃった方が、処理が早いです。

プログラムで、
ファイルレコード1件ごとにSELECT投げて、
UPDATEかINSERTか判断して実行して、
これを１０００回繰り返す。コレは悪です。やってたら犯罪です。

一括でファイル読み込んで、
一括でSELECT投げて、
REPLACEで一気に１０００回更新

置き換えれる時は迷わず変えてしまいましょうネ

以上。か＾－＾つんがお送りしました。

かーつん MySQL, データベース

二日連続で失礼します。
チョコボールです。

昨日の天気は荒れに荒れてましたね。。
今も荒れてますが。。
長時間雷鳴りっぱなしの豪雨！
住まいは東京の西の方なのでモロに影響受けました。。

PCが壊れるとまずいので家帰ってからずっとPCの電源抜いてました。
というのも、落雷で家電製品が壊れた…なんて話をよく聞くからです。

一か月ほど前、近所で落雷があり、同じアパートの住人がPCの電源が立ち上がらなくなった…と悔やんでいました。
その時、自分は家にいましたが、危険を感じて電源引っこ抜いていたので運よく無事でした。。

ここまで落雷が多いと、雷サージ対策をしなきゃまずいって気持ちになってきます。
今度電気屋に行った時は絶対買おう。。

昨日から久々にCakePHPを触ることになりました。
弊社コマースシステムの管理機能追加です。

現在のCakePHPのバージョンは1.2ですが、弊社のシステムはバージョン1.1で構築したもの。

ほぼ初心者の頃、いきなりCakePHPを触っていた自分はDB関係のデータ取得等はメソッドを使いまくっていたのでSQLになかなか慣れませんでした。
他人が書いたSQL文中のJOINという文字を見るとどうなってるか分からず、拒絶反応を起こしてしまう…というようなひどい状態が続いていました。
テーブルを結合してデータを取ってきてくれたりするCakePHPのアソシエーション機能は非常に便利ですが、理解しないままこれを利用しているといつまでたってもSQLについて詳しくなれません。。

SQLはできるだけベタに近い状態で書いた方がフレームワークを理解していない人でもすぐ理解でき、保守は楽だと思います。
無駄なSQLをたくさん流すと負荷がかかって遅くなりますし。。
処理が重くなるところはできるだけ簡素で効率のいいSQLを書きたいものです。

一通りWEBアプリケーションに精通している方達はこのようなフレームワークを使った方が高速に開発できると思います。

CakePHPの好きなところはすごく好きなんですけどね。。
システムとして見るとかなり勉強にもなります。

パフォーマンス性や保守性を重視するか、高速開発を重視するか…。

ただ間違いないと思うことは、処理が重いシステムは誰も嫌がる…とういことです。

MoriMoriMoriMori MySQL, PHP, Tips, データベース