データベースのプライマリーキー

たとえばフォルダという概念のデータベースがある場合、フォルダにはさまざまなデータベースがぶら下がる事ができる事は簡単にわかると思う。

そこで主キーをIDなどを利用して、フォルダデータベースで利用されているIDは登録できなくするなんてこともするが、私の場合は常にプライマリーキー＝autoincrementなもんで、競合するIDが続々出現しているわけだ。

この理論に対抗するためには、各データベースの登録予想最大数を決めておき、十分なスペースをあけて、autoincrementの開始値を重複しないように工夫する。

なんてことも今だけの回避策なので、隙間なくautoincrement番号でフォルダデータベースという、区分を使いこなしたい場合は、フォルダキーテーブルを作る。

フォルダにぶら下がる可能性のある輩たちはこのフォルダキーテーブルを通して、autoincrement番号を配布していただくわけだ。

はっきりいってこれを今使ってみたりしたが、かなりめんどくさい。

フォルダのように矛盾の生じないテーブルに対して行う分にはある程度の慣用度があるように、私個人的には感じるが、共用したいが関連性の薄いテーブルの組み合わせの場合は、なんとなく作る事がおっくうになってしまう。



その他にこのような共用利用される可能性の高いテーブルでいくと、利用する画像を登録しているテーブル。

商品や伝票やメッセージから参照される可能性があり、番号が重複するわけにはいかないが、ほぼ同じ構造の追加テーブルを各地に作るか、共用するしか管理方法が難しい。

ページ間引数（クエリにマルチバイトの場合）

特にheader(location)とかのアドレスの後方に?name=エチ！　とかつけるなら、

エッチ！

を

$value = urlencode("エチ！");

とかしてからつけなさい。
IEとまるから。

mysqlテーブル INDEXの有用性とexplain

データベース構造の設計が甘い筆者は、１クエリ１．５秒もかかるようなクエリを完成させたのだが、
そのクエリをexplainし、そのまま参照しているカラムにPrimaryKey（他のクエリから別参照が起こらないのであればだが）や、INDEXを設定することで、なんと0.3秒にまで速度を改善することができた。

10000件のデータで1.5秒が0.3秒になったということは、50000件まで乗っても大丈夫！！稲葉物置！みたいな状況に陥った。

みんなもexplainしてeq_refを愛して病まないテーブル設計をしようぜ！