| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
先日書いた記事 に関してなんだけど、よくよく考えると「型に縛られない素晴らしい言語なんだ！」って強調したかったのかもしれない。この関数の作成者は。
なんせ、一つの関数の戻り値がboolean型だったり、int型だったりできるんだもん！すごいじゃん！ってなもんだ。
だとしたら、完全な独り善がりだよね。プログラマは、そんな「型」なんてややこしいこと考えなくても使えることをPHPの利点だと思ってんのにさ。もっとシンプルに行こうよ。わざわざ戻り値の型を変更することないよ。めんどいし。
MySQLのネタをいくつか書きましたが、MySQLの罠にはまってしまいました。リリース前で良かった。危ない危ない。
その罠とは、auto_incrementを指定しても、指定した項目を単独のUNIQUEインデックス(UNIQUEであればいいので、PRIMARYでもOKです)に指定しないと、最大値のレコードを削除したらインクリメント値が再利用されてしまうという罠です。
再利用されないのが常識かと思ってたのですが、違ったようです。まあ、マニュアル読んだら、ちゃんと書いてあるんですけどね。ローカルな仕様で悩むってのは、こういうことなんだなぁ。
array_searchという関数があるのですが、これの戻り値が問題なんです。失敗したときはFALSEを返して、成功したらインデックス値を返すらしい。
ということは、先頭が一致した場合は0じゃねーか（FALSEは内部的には0と同じ扱い）。
どうやって、見つかったか見つかってないかを判断するのか途方にくれて、結局別の関数を使って処理を進めちゃいました。
んで、それまで本とかWindowsヘルプファイルで関数確認してたんだけど、さっきWebのマニュアルを開いてみたら、比較演算子を変更したら良いらしい。
http://php.s3.to/man/function.array-search.html
最初からこっち見とけば良かった。
っちゅーか、この程度の関数なら自作したが早いよね。FALSEじゃなくて、-1を戻すようにすれば良いのに。型の概念が希薄な言語なんだから、せめて戻り値ぐらいは型を合わせておこうよ。関数の設計者は、何考えてたんだろうな。
やっぱり、初心者だけの事はありました。
MySQLのインデックスを選択するオプティマイザが馬鹿なので、「MySQLうんこー」とか小学生並みの罵倒をしてたのですが、どうやらインデックスの作成方法かテーブルの作成方法か、MySQLの動作モードか、このどれかに問題がありそうです。
というのも、インデックスを使用するか使用しないかという選択は、統計情報を元にオプティマイザが判断を行うのですが、速いインデックスを選択してくれなかったテーブルのインデックス情報を見ると「Cardinality」がNULLになってました。
つまり、統計情報がこれっぽっちも存在してなかったことになります。
となると、正常な判断ができるわけもなく、MySQLのオプティマイザはなんとなくこっちかなって感じで遅い方を選択してるようです。
というわけで、インデックスに使用してる項目の性質などを考えたら、適切なインデックスを指示しつつSQL文を書いた方が良いようです。
というか、統計データをなんで取ってないんだろう…。
この前アップしたときは、ショボすぎたので、ちょっとだけバージョンアップ。このブログと、ゲーム日誌の方と二つの情報が表示されます。これを利用して、簡易グループサイトみたいなのができないかと考えてます。
http://homepage1.nifty.com/aoten/blog_group.html
そして、その私がやりたいことをほぼ実現してるJavaScriptを発見したので、それのデータ部を書き換えてアップ。（参考：http://web.paulownia.jp/script/xml.html）
http://homepage1.nifty.com/aoten/rss/rss.html
やっぱり、このあたりの技術は面白すぎます。仕事落ち着いたら、何か作ってみよー。
JavaScriptとRSSとinnerHTMLの組み合わせが凄すぎます。今、仕事でやってるプロジェクトが片付いたら、暇を作って私の書いてる日記やらブログやらの更新情報をトップページに載せる奴を組み込みます。
名づけて記述するブログを分散化することによる、負荷分散とリスク分散の仕組み。
って、そんなカッコイイもんじゃなくて、面白いぜーってやりたいだけです。いやー、innerHTMLの仕組みが凄すぎますね。ワクワクしてきました。
というわけで、全然PHPとは絡んでなさそうに見えますが、PHPもからませて楽しいことがやりたいだけです！初心者なりに楽しい事ができるといいなぁ。
[追記] http://homepage1.nifty.com/aoten/blog_group.html こんな感じで作りってみたい。
どうも、インデックスを使った場合はハードディスクのヘッドのシークが発生する場合を避けるために、「わざと」インデックスを使った検索をしないケースがあるようです。
確かに、ハードディスクはメモリと比べて数桁の速度差があり、シークが入るともっと遅くなるでしょう。プライマリインデックスなら別ですが、それ以外のインデックスはハードディスクの物理的な箇所が連続してるわけではなく、あっちにいってはこっちに戻ってみたいなヘッドのシークが発生するのは間違いありません。
そういう理由から、↓の記事のような動作をMySQLがしているようです。
つまり、私の勉強不足だったわけで…。このあたりのチューニングは奥が深いですね。
PHPというより、MySQLなんですが、PHPからMySQLを利用してるんで、このあたりのカテゴリ選択は目をつぶってください。
さて、MySQLを使うようになって、今まで使ってきてたParadoxとかDBISAMとかとは違った、本格的なDBMSの世界へ一歩を踏み込みました。
今までで一番感動したのは、explainによるSQL文の解析です。
explainを利用して、インデックスがちゃんと使われてるかどうかを確かめることができるなんて、すばらしいです。今までのはDBMSではなかったので、このあたりの機能が欠けてたことに気づかされました。
さて、そのMySQLですが素晴らしいことばかりじゃありません。こりゃあかんだろーって事もあります。
その一つが、インデックス選択が駄目駄目すぎること。ある二つの項目で検索するので、その二つの項目に二次インデックスを作成したにも関わらず、明示的に指定しないと使ってくれません。んで、あれこれ調べてみると、その二つの項目のうちの一つがDATETIME型なんですが、このDATETIME型に対して
selec * from hote_table
where hoge_code = 1 and hoge_date < '2005-05-17'
なんて検索をしちゃうと、駄目みたいなんです。んで、CASTしてみたら上手くいくかと思って
selec * from hote_table
where hoge_code = 1 and hoge_date < CAST('2005-05-17' AS DATETIME)
なんてのも試してみましたが、これでも相変わらずインデックスをきちんと使ってくれません。
仕方ないので、最終的には、
selec * from hote_table use index(hoge_index)
where hoge_code = 1 and hoge_date < CAST('2005-05-17' AS DATETIME)
とするしかありませんでした。ちなみに、USE INDEXを使った場合、CASTを明示的にする必要はありません。つまり、
selec * from hote_table use index(hoge_index)
where hoge_code = 1 and hoge_date < '2005-05-17'
でも同じ結果になります。むむむむ…。なんてうんこなんだ、MySQLめ。
皆さんも疑問に思ったことはありませんか？何故、Windowsのログオン時にはNumLockが切れているのだろうかと。世間一般では、数字や英文字をランダムに混ぜたパスワードが強度が高く理想的であるという話であふれています。なのに、何故数字入力が楽なテンキーが標準状態では使えなくなっているのでしょうか。
もちろん、一度設定を変更してしまえば、NumLockはついたままになります。でも、必ず最初は切れているんです。
これは、テンキーによる入力は後ろから覗き見られた場合、非常に分かりやすくパスワードが漏れてしまう可能性があるためなのです。いわゆるショルダーハッキング対策という奴です。
ですから、ログオン時のパスワードに数字が含まれているからといって、NumLockをONにしてテンキーで入力することは極力控えましょう。これは習慣にしておいた方がいいことです。
Recent Comments