あり

情報システムと言うのは情報をやりとりするためのシステムなので、その情報をどこかに保持しておくのは基本中の基本です。
その方法のひとつ（と言うか主流）はデータベースだと思います。

データベースにもいろいろありますが、現在ポピュラーなのはやはりリレーショナルデータベースと言うやつで、
ざっくりと言えば、表形式にデータが保存されているものです。

これの名前などを定義する場合には、自分がかかわってきた場合には日本語（と言うか、１バイト文字以外）の名前を付けたりするのは
ご法度な雰囲気があったのですが、最近は日本語の表名列名なんかを使う場合も増えているような気がします。

確かに今は、文字コードはUnicodeを使うのが主流で、別に問題ないのかもしれないのですがどうも気持ち悪い。
プロジェクトの指針で「テーブル名などは基本日本語で！」とか出たとしても明快に反論出来ないと思いますが、
日本語名を使うのがいやな理由を考えてみました・

・記号を使われたときにバグりやすいんじゃないか？
つまり、全角の「％」や「？」や「（）」とか、SQLのシンタックスに影響してくる文字を使われたらどうするんだ、と言う話ですが、
これは全角記号は使わない、と言うことにすれば良いし、使っても全角文字であればSQL文に影響はないですね。

・O/Rマッピングがしにくいんじゃないか？
O/Rマッパーは要するにプログラムから出来るだけデータベースのインターフェイスを隠蔽してみる試みですが、
データベースのレコードひとつにあたるEntityオブジェクトはテーブルのメタ情報から自動生成できることが多いです。
そのときに日本語名が使われてたら・・・。
しかし、（自分が知っているO/Rマッパーの）Javaや.Netはメソッド名やメンバ名に日本語が使える場合が多いですね。
なのでそんなに問題ないのかも。

・Web系システムの場合は文字コードが違ったら完全オジャン
javaや.Netなんかは確か内部的にはUnicodeでリテラルを扱うので問題ないかもしれないのですが、
phpやperlなんかはまだ完全にそうではないです。Unix系でマルチバイト文字なら普通EUC-JPですよね。
しかしこれはDBどころかシステム全体の問題になるのであって、そこはまずクリアしておく課題なはずなので問題ないかも。

・EclipseなどのIDEで、コード補完機能の使い勝手が落ちる
まあ、SQL文をリテラルで使うならぜんぜん関係ないですけど、前述のO/Rマッパーを使った場合、日本語フィールドだとインクリメンタルサーチが完全に機能不全になりますね。
たとえば、DeptテーブルのDeptCodeを補完したい場合は、Dept、と書いて接続子（ピリオドとか->とか）まで書いて、「D」キーを押せば「DeptCode」が補完候補に出たりしますが、
Deptテーブルの「部門コード」を保管する場合は、日本語で「部」まで選択されないと補完候補までたどり着けない。
しかし大体、Entityにアクセスするコードを書くのはそう多いわけではないので問題ないか・・・。

・パフォーマンスが落ちる
いや落ちない。と言うかここはパフォーマングチューニングするにはあまりにも効果薄そう。

ん～、やはり使うのはいやなのは趣味の問題なのか。
明快な反論が出来ないですね。

よくパソコンのメモリとかの裏に「パリティ有」とか書いてあったりします。
昔から聞いたことがあった単語だったのですが、まあいいやと思っていたのですが、
最近それを知る機会があったので、せっかくなのでメモしておきます。

まずWikpediaの記載によると、

パリティビット(parity bit)は、コンピュータと通信において、与えられた二進数に対して全体の奇偶性を保つために与えられる一桁の二進数(つまり 0 か 1)である。パリティビットは最も単純な誤り検出符号である。

もうこの時点で意味がわかんない。「奇遇性」ってヒマがあれば追ってみるけど別にいいやと思っちゃいますね普通。

パリティチェックの基本については、以下ページがすごく参考になりました。
通信基本用語 – 誤り制御 | LINEEYE
http://www.lineeye.co.jp/html/term_ayamari.html
エラー制御
http://www.asahi-net.or.jp/~ax2s-kmtn/error.html

まずこれは、あるデータを通信する場合に、そのデータが正常なものなのかをやんわりと検証するためのものです。
送信側は知っていても、受信側は受信するだけで、それが正しいのかどうかはわかりません。

なので、送信するデータを元に、明白な計算結果を一緒につけてあげるのがパリティビットの役割です。

たとえば、「A」も文字コードは10進数で「65」で、1バイトで表現できます。
これを2進数に変換すると「01000001」になります。

パリティビットのルールは、送信側と受信側で決めておくことが出来ますが、たとえばパリティビットは偶数です、と決めたとすると、
上記の「01000001」の中の1の数が偶数であれば、最後に「0」を付与して送信します。
（パリティビットは奇数です、と決めた場合は、パリティビットを合わせた1の数が奇数になるように送信側で調整します。）

受信側は、010000001と「0」をあわせて受信しており、1の数がちゃんと偶数であればOKとします。
途中、通信状態によりどこかのビットが反転（0が1、1が0）になった場合には全体として偶数にならないのでエラーを検出できます。
ただし、この場合はたまたま2つのビットが反転した場合にはエラー検出できません。
全体として奇数か偶数かしかわからないので。これを垂直パリティ方式と言います。
これがWikpediaの「奇遇性」と言うことなんだろうな。

そこで、1キャラクタだけではなく、ある単位でパリティビットを与えて、それがどうなのかを計算する方法があります。
それが水平パリティ方式と言うことになります。

たとえば、「ABCD」と言うデータがあったとしたら、これを2進数にしてリストすると、
A:01000001
B:01000010
C:01000011
D:01000100

となります。これの垂直パリティビットは、偶数パリティの場合は「0010」になりますが、これのタテのパリティビットも算出して送ります。
これをBlockCheckCharacter(BCC）と言うそうですが、以下のようになります。

A:01000001 0
B:01000010 0
C:01000011 1
D:01000100 0
————–
00000100 1

これで、垂直パリティと組み合わせると、多少はエラー検出率があげることが出来ます。
ただ、これはほんとに低レイヤーの処理の話ですなぁ。

忙しいのにPHPデバッグ環境構築したい場合はそうないかと思いますが、
現在、どこかのサーバーで動作しているPHPモジュール群をローカルで動作させたい場合の手順をメモします。

念のため、検証した環境は
・Windows Vista SP2
・Eclipse Platform 3.5.1.R35x_v20090910-9gEeG1_FthkNDSP2odXdThaOu9GFDPn83DGB7

です。
PDTと、XAMPPは既にインストールされている事が前提ですので、入っていない場合は以下記事から入れてやってください。
Installation of PDT on Eclipse3.5
Zend Debuggerインストール（xampp編）
記事の投稿日よりバージョンが上がっていたら、最新のバージョンをお勧めします。

既存のPHPモジュールをEclipseにインポート

現在動作しているPHPモジュールを、FTPやSubversionでもなんでも良いので、まずはローカルPCにコピーします。
今回は、svnからチェックアウトしましたので、subversiveが入っている前提ですが、FTPで持ってきた場合は、
PHPエクスプローラー右クリック→インポート→一般→ファイルシステムでまずはEclipseのプロジェクトと認識させます。

PHPプロジェクトへ変換

インポートしただけでは、単なるファイルセットなので、これらをPHPのプロジェクトに変換します。
プロジェクトを右クリックして、構成→Add PHP SupportでOKです。

デバッグサーバーの設定

サーバーにはXamppのApacheを使用します。ここのAliasに先ほどインポートしたプロジェクトのルートを記載します。
具体的には、(Xamppインストールディレクトリ)\apache\conf\httpd.confに以下を追加します。

Alias /testPHP "D:\Workspace\test\testPHP"
<Directory "D:\Workspace\test\testPHP">
Order allow,deny
Allow from all
</Direcotry>

とか。

デバッグサーバーの構成

プロジェクト右クリック→デバッグ→デバッグサーバーの構成で、新しくデバッグサーバーの構成を作成します。
上記では、
http://localhost/testPHP/
というURLになるので、それを踏まえて以下のようにして構成します。

ファイル：/testPHP/index.php
URL：自動生成（デフォルト）

これでXamppのコントロールパネルからApacheを起動しておいて、Eclipse環境から先ほど作成したデバッグ構成で起動してみます。
とりあえず動かすだけならこれでOKなはずです。
細かいことは置いといて、ZendDebuggerの設定だとステップ実行出来ないので、単純にXDebugで動かしてもいいかもしれません。
（これ昔からそうだったなぁ。）