お疲れ様です
のびーにょです
今日はDBオペレート時の話
自分はUPDATE文やDELETE分流す時には指差し確認を行っています。
なぜかって
怖いから
昔、本番環境のDB触ってるときにUPDATE文流す時に、”WHERE”句を付けずに実行した事があります。
会員のゲーム状況を保存しているテーブルで、それが一気に全部書き変わっちゃって・・・
あの時のあせりと言ったらもう、やばかったですよ。
幸い200件ほどしかテーブルにデータが入っていなかった(ゲームごとに違うテーブルでリリース直後だった)ので
手作業で戻すことができました。
また、上司が間違ってBBSのデータをdropしたことがありました。
あの時はバックアップから復旧したはずですけど、バックアップ取ってから書き込まれた内容は消えてしまっています。
そういう経験を見たり、自分でやっちゃってからは必ず指差しで”WHERE”句が付いていることを確認してから実行しています。
変更する物を先にSELECTで変更する内容、件数を確認してSELECT文を改変してUPDATE、DELETE文にするのもいい方法です。
それでも指差し確認してますけど。
皆様もDBを操作する場合には十分ご注意ください。
と、言っても自身がミスしない限りはきっと無理なんだろうなぁと思います。
プログラム組んでるとDBなんて日常的に操作する物だから、慣れで適当になってしまいますよね・・・
それでも自分で指差し確認をしているのはあの恐怖をもう二度と経験したくないからです。
皆さんも頭の片隅に入れておいて下さいね。
のびーにょ Tips, データベース
本日投稿2個目、チョコボールです。
DBから引っ張ってきた文字列をセレクトボックスで表示させる箇所で、
長ったらしい文字列があるせいでデザインが崩れてしまっている！という指摘を受けました。
指定した幅以上は「…」で表示するという、よくある表示方法で対処しようと思い、
substr関数等であれこれ試していましたが、mb_strimwidthという関数を使うといい感じでした。
mb_strimwidth(【文字列】,【開始位置のオフセット(最初の文字は0)】,【幅】,
【丸めた後にその文字列の最後に追加される文字列】,【文字エンコーディング】)
表示部分で『この横幅以下に抑えたい』という時に使えます。
文字コードに依存せず、第3引数の数値は半角を幅1、全角を幅2とします。
文字数ではありません。
また、第4引数も含めた数値になります。
$str = "あいうえおかきくけこ";
$str2 = "This is a pen.";
echo mb_strimwidth($str, 0, 10, '…', 'UTF-8');
echo '<br />';
echo mb_strimwidth($str2, 0, 10, '…', 'UTF-8');
上記の結果は下記のようになります。
あいうえ…
This is a…
全角の文字の場合でも半角の文字の場合でもだいたい横幅が揃うはずです。
smarty側で書く場合はこんな感じです。
{$str|mb_strimwidth:0:10:'…':'UTF-8'|escape}
MoriMoriMoriMori PHP
チョコボールです。
PHP言語での文字コードの変換といえば『mb_convert_encoding』関数。
mb_convert_encoding(【文字列】,【変換後の文字コード】,【変換前の文字コード】);
返り値は変換後の文字列です。
以前書いた記事、CSVファイル出力関数の時にも使いましたが、出力する直前に、
$str = mb_convert_encoding($str, 'SJIS', 'UTF-8');
のように使って文字列の文字コードを変換したりするわけです。
上記の場合、UTF-8からShift JISに変換です。
第3引数→第2引数
第3引数を指定しなかった場合は、内部文字エンコーディング
(php.ini の mbstring.internal_encoding の値)を使用することになります。
配列中の文字列の文字コードを一気に変換したい時、
foreach等でループさせてmb_convert_encodingかけて…
とかしなくてもmb_convert_variables関数で一行でいけます。
mb_convert_variables(【変換後の文字コード】,【変換前の文字コード】, 【文字列、配列、オブジェクト】);
変数はカンマで区切って複数指定できます。
第2引数→第1引数
mb_convert_encodingと違い、返り値は変換前の文字エンコーディングを返します。
失敗した場合はFALSEを返します。
$ret = mb_convert_variables('SJIS', 'UTF-8', $array);
上記の場合、返り値$retはSJISになります。
単に変換を掛けたいだけの場合は
mb_convert_variables('SJIS', 'UTF-8', $array);
の一行で。
一見似ている関数ですが、引数の順番の違い、返り値の違いに注意が必要です。
MoriMoriMoriMori PHP
海外からのアクセスを防ぐ。
そんなお困りな方は、.htaccessで大体のことはできます(サーバが.htaccessに対応している必要がありますが・・)。
order deny,allow
deny from all
allow from .jp
とすれば、jpドメイン以外からのアクセスを防ぐことはできます。
しかし、これだけでは、apacheの設定具合等によっては普通にアクセスできてしまう場合があるので、IPで直接制限をかけた方が良いかなと。
JPNICが管理しているIPアドレスは以下から確認できるので、それのみアクセスできるようにすれば、一応国内からのみアクセスということができます。
http://www.nic.ad.jp/ja/dns/jp-addr-block.html
設定方法としては以下。
order allow,deny
allow from all
deny from 210.128.0.0/11
deny from 221.16.0.0/12
・
・
.htaccessサンプル(一応2008/11/27付のデータで作成)
ずらっと、大量に記述する必要がありますが、こんなに多量にあってもIPv4はもう喝々で、更に桁数の増えるIPv6にそのうち移行するとか言う話も出てきていたりします。
そんな感じ。
下音タヌキ Apache, Tips
とあるプログラムで気になったことをメモ。
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, データベース
