MySQL テーブルのIDにbigintはどうか

毎週1回必ず40万レコード追加するテーブルがあります。
データ型はintで十分です。
unsignedにして約40億レコード登録できる計算なので約1万日は使えます。
毎週1回の処理を1万回なので約2,500ヶ月・・200年くらいの計算ですね。

それまでそのシステムが動いてるとは思えないし、僕は間違いなくこの世にはいません。

そのテーブルはintで十分なテーブルだったんですが、あまりそういう計算をせずに作ったので、bigintでやってしまいました・・何となくデカいデータになりそうだと思ったので・・・
実際のところ、int unsignedで毎日40万レコード追加だったとしても20年以上いけます。
bigintをIDのauto_incrementで使う時なんて、ちっぽけなアプリを作ってるうちはなさそうですね。
Twitterみたいなのを作ったら必要かもしれないけど。

もう納品したし、問題なく動いているので別にいいんですけど、やっぱりこういうのはしっかりと計算してからやらないとダメですね。

VARCHARの文字数とかも結構適当にやってしまいます。
メールアドレスは300くらいとか住所は200とか、電話番号は20とか、ちょっと余裕があるくらいで調整してますが、これも実際どうなんでしょうか？
余裕は必要だけど、余りすぎても問題だと思います。

今回納品した制作物と関連する別のパートで、別の業者が手がけてたんですが、VARCHARでやるようなところを全部TEXT型で宣言してました・・
これもちょっと良くないんじゃないの？と思ったけど、問題なく動いているのでいいのかなぁ？？

何かプログラマーって結構適当ですよね(^^;
僕も含めて、なんちゃってプログラマーが増えすぎたのかな？
本物のプログラマーならこんな適当な仕事しないでしょうね。

悪いのは厳しい納期だ！と自分に言い訳をして放置します(w
今回のはコメントもほとんど書いてないや・・もうどんなプログラム書いてたか分からん(--;

ASUSのU30Jc-QX075VSを買おうかな・・

今、次のパソコンをどうするか考えているところです。
Windowsにすることはもう確定しました。

たまたまソフマップに寄ることができたので、ちょっとパソコン見学してみたところ、ASUSのU30Jc-QX075VSが良さそうな感じでした。

Windowsのノートって、今までPentium Mの頃のMebiusしか使ったことがないんですよね。
それまではショップブランドのデスクトップが中心だったし、ノートをメインに使うようになったのもここ4、５年の間です。
今はMacBookだし、Windowsノートを買うのってホント久しぶりです。

ASUSのノートってどうなんだろう？
値段が安いのは嬉しいです。
でも、パソコンは長く使うものだから、値段で妥協した買い方は絶対にしたくないです。
例えば、安物のパーツを使って安いパソコンを作っているのなら、僕はもう5万払ってでも良いパーツを使ったパソコンにしたいと考えます。

まぁスペックだけで見るなら、かなり理想に近い感じです。
64bitでCPUがi5、液晶が13.3インチ、メモリはデフォが2Gだけど、増設して8Gにします。
仮想環境を作るからi7が本当は欲しいんですけどね・・。
まぁ13.3インチなのでそこは仕方ないのかな・・。

メモリが2Gしか入ってないことが逆に良いかもしれないですね。
大概のパソコンは2Gのメモリ２枚で4Gで売っています。
これを8Gにしようと思ったら２枚とも外して4Gのメモリ2枚買わないといけないんですよね。かなり無駄です。

本体が安いからSSDへの換装もちょっと視野に入れてるんですけど、まだ高いですね・・。
しばらくはHDDで様子見た方がいいのかな・・

MacからWindowsに乗り換え〜次は64bit機で仮想環境を

今年やっとMacに乗り換えたところですが、またWindowsに戻ることにします。

やっぱりテキスト処理の問題でMacはちょっと使いにくいことがあります。
エディタで使ってるmiが悪いのか、Macそのものが悪いのかは分かりませんが、3Mb程度のテキストファイルの正規表現置き換えなんかで固まってしまいます。

5,000行程度のログファイルを一旦クリアしようと全選択して削除した時も固まりました。
元々テキストファイルを扱うことが多いので、こんなことではダメなんです・・

と言ってもMacをやめるわけではありません。
次のMacはWindows上の仮想環境で動かします。

次のパソコンは仮想環境をもっと充実させたいので、64bit機にメモリ8G積んでVMWare Workstationを導入するつもりです。

母体となるOSはWindows7になると思います。できればProfessionalがいいかな。
母体は必要最小限のアプリだけをインストールして、仮想環境に開発環境を整えていきたいところです。

多分Web閲覧とか普段使いのOSは仮想環境のMacになるような気がします。

XERAでPHPのsystem関数を使ってmysqlのバックアップデータを復元

XREAに限らず、PHPがセーフモードで動いているサーバーがけっこう多いと思います。

MySQLのバックアップデータをWeb上で復元するという処理が必要だったので、PHPのsystem関数を使わないといけませんでしたが、system関数ってのはセーフモードでは動かないので、XREAの場合はCGI版のPHPで実行しないといけません。

まずは.htaccessを編集して、system関数を実行するphpファイルをCGIとして動かすようにします。

<Files ファイル名.php>
AddHandler application/x-httpd-phpcgi .php
</Files>

それでsystem関数でバックアップデータ復元のコマンドを指定するんだけど、ここで一回つまずいた・・

$command = "mysql -u ログインID -pパスワード データベース名 < /virtual/XREAのユーザー名/バックアップファイル";
system($command);

と書いて実行してみたけど、うまくいかない。
sh: mysql: command not found となってしまいます。

パスが通ってないのかな？と思ってSSHで同じコマンドを実行すると正常にバックアップを復元できました。
パスは通ってるのに・・と思ったけど、とりあえずsystem関数でmysqlのフルパスを指定してみました。

$command = "/usr/local/mysql/bin/mysql -u ログインID -pパスワード データベース名 < /virtual/XREAのユーザー名/バックアップファイル";
system($command);

こうするとうまくいきました。

phpMyAdminからだと、アップロード可能容量の制限で大容量のバックアップファイルを復元することができないと思うので、一度サーバーにFTPでバックアップファイルをアップしてからこの方法で復元するということもできますね。

XREAが重い、データベース消えた、FTP繋がらない

XREAは安いからよく使うんだけど、最近ちょっと使い物にならなくなってきた感があります。

まずFTPの接続が悪くなってきましたね。
僕が使う時間帯が丁度重い時間帯なだけかもしれませんけど。
大体深夜の1時くらいです。

繋がらなかったり、アップロード中に切断されたり、接続するのにやたら時間がかかったり。
まぁそこは安いサーバーだから我慢します。

ちょっと酷かったのが、データベースの消失です。
あるサイトでWordpressを使ってるんだけど、カテゴリを管理するテーブルが丸々消えたことがあります。
記事のテーブルじゃなくて良かった。

原因はXREA側なのかWordpress側なのかは不明です。
テーブルが消えた時の状況というと、アクセスした瞬間「データベースに繋がりません」と出て、すぐにリロードすると今度は画面は出たけど記事が出ない。
それでしばらく待っても記事が出ないから、DBを直接見てみたらカテゴリのテーブルが消えてたという感じです。
まぁXREAが原因でしょうね・・

そのサイトは遊びのサイトだから別に消えてもいいんだけど、もしそれが重要なサイトだったとしたら大変なことです。
重要なサイトはXREAで運営しない方がいいと思います。
データベースを使わないなら別に問題ないかもしれないですけどね。
ファイルが消えたことは今のところありません。

まぁ趣味と実験用のサーバーとしては便利だと思います。
本気で運営するWebなら、格安サーバーはやめてもうちょっと良いサーバーにした方がいいでしょうね。

MacではなくWindowsを使わなければいけない時

かなりMacかWindowsかで悩んでるんですけど、またWindowsに傾くことが起こりました。


100万行近い規則正しいデータ(CSVのような感じ)の置き換えないといけないという場面がありました。

Macのエディタはとりあえずmiを使っているので、まずはmiでそのファイルを開きました。

データが大きいからなんたらかんたら・・とメッセージが出たけど構わず開く。
開くのに少し時間がかかりました。

そして、正規表現で置き換えを実行・・・・・






固まりました。


それどころか、一度再起動しないと重くてどうしようもない感じでした。

ちょっと急いでたので、「また落ちたら・・」と思うとmiを使う気になれず、VMWare FusionでWindowsを起動しました。

Windowsで愛用しているサクラエディタを起動。
多少開くのに時間がかかったものの、プログレスバーで何となく進捗が分かるので安心でした。

そして、同じ正規表現の置き換えを実行。
これが速かった！

当然100万行近いデータなので数秒は待ちました。
ここでもまたプログレスバーが出てたので、安心して待てました。

Macは大きいファイルの扱いに弱いのか・・
よく分からないけど、とにかくサクラエディタは使いやすいです。

やっぱりWindowsが良いのかな・・

WindowsでもMacが動く・・

詳しい人にしてみれば当たり前なことかもしれないんですけど、こんな記事をみつけてしまいました。

http://www.lifehacker.jp/2010/07/100716virutalbox.html

Windows上でMacを動かすことができるということです。

Intel CPUのMacでWindowsを動かすのと違って動作の保障はないと思いますけど、ちょっと画面確認とかする程度なら十分だと思います。

この方法を使ってWindows上のMacでiPhoneアプリの勉強をしている人がいます。

やっとMacに慣れてきたところなんだけど、この記事を見てまたWindowsに戻ろうかと考えてしまいました。

やっぱりMacにはOfficeの問題があるので、WindowsベースでMacが動いてくれる方が仕事はやりやすいです。

普通に趣味として使うだけならMacの方が楽しくていいんだけど、趣味用と仕事用に1台ずつ買える程裕福じゃありません。

本気で次もMacを買おうと思ってたんだけど、今はかなり気持ちが揺れています。

元々Macを買った初期衝動はWindowsも動くし・・というのが大きかったです。
その理由はこの記事で崩れ去りました。

今はMacにも慣れて結構お気に入りです。
開発環境も自分なりに整えたし、Spacesをうまく使ってそれなりに快適にできています。
でもOffice関連で仕事では不便しています。

次どうしようか・・悩みます・・。
ぶっちゃけかなりWindowsに傾いてます。

MySQLでNOT INの代わりにNOT EXISTSを使うと速い

ちょっとした情報を取り出す時のクエリが30秒ほどかかったので、何とか改善できないものかと試行錯誤してみました。

２つのテーブルがあって、仮に

■顧客情報
t_client_info ( client_id, name, address)
■顧客履歴
t_client_history (id, client_id, visit_date)

とでもしましょう。

visit_dateはdate型ではなくてint型でYYYYMMDDの形式とします。
あとは見たまんまなのでテーブルの説明は省略ます。

2010年の元旦から1年以内に来店した顧客の住所と最終来店日を取得するというクエリです。
1年のうちに1回しか来なかった人は省くことにします。

SELECT i.client_id, name, address, MAX(visit_date) as vdate
  FROM t_client_info AS i
  LEFT JOIN t_client_history AS h
    ON i.client_id = h.client_id
 WHERE visit_date > 20100101
   AND i.client_id NOT IN (
     SELECT client_id
       FROM t_client_history
      WHERE visit_date > 20100101
      GROUP BY client_id
     HAVING COUNT(visit_date) = 1
   )
 GROUP BY i.client_id, name, address
 ORDER BY vdate DESC

こんな感じでやってみると、30秒かかりました。
サブクエリ単体の実行速度はそんなに遅くなかったので、多分NOT INがダメなんだろうなと思って、NOT EXISTSを使ってみることに。

SELECT i.client_id, name, address, MAX(visit_date) as vdate
  FROM t_client_info AS i
  LEFT JOIN t_client_history AS h
    ON i.client_id = h.client_id
 WHERE visit_date > 20100101
   AND NOT EXISTS (
     SELECT client_id
       FROM t_client_historr
      WHERE visit_date > 20100101
        AND i.client_id = client_id
      GROUP BY client_id
     HAVING COUNT(visit_date) = 1
   )
 GROUP BY i.client_id, name, address
 ORDER BY vdate DESC

こんな感じになりました。
これで一瞬で表示されました。

NOT INの方が読みやすいんですけどね。
ここまで速度に差が出ると可読性なんてこだわってられません。