CentOSにMeCab+Senna+MySQLを入れる
日本語で全文検索をするために MySQL に Senna を組み込むメモ。少し前は個人ニュースサイトめぐり→日記書きに数時間を要していた私が次に目をつけたのがRSSめぐり→はてブ登録なのだがそれでも依然として数時間かかる。そんなあなた (私) に朗報です。私の代わりにブックマークしてくれるエージェントを作ればいいのです。そしてそのエージェントが今日よく使われていた単語やタグとか出してくれて、1次ソースAについてBさんとCさんとDさんがそれぞれの立場でこんなことを書いているとかいうのが俯瞰できて、さらにあとから検索とかができればいいのです。いまホッテントリを見なくてもいいのです。あとで検索できればいいのです。Googleが拾ってくる量は莫大過ぎるし個人で把握できる範囲にも限度がある。ユーザの皆さんが勝手に重み付けしてくれるならそれを使ったらいい。先週の週刊東洋経済を読んで悟った。いやなんか変
なければ INSERT、あれば UPDATE
間違って主キーと同じ値を含む行を挿入しようとしたらエラーを出して教えてほしいとき INSERT INTO test VALUES(1,100); とすると、ERROR 1062 (23000): Duplicate entry '1' for key 1 というエラーが出る。 間違って主キーと同じ値を含む行を挿入しようとしても無視して処理を続行してほしいとき INSERT IGNORE INTO test VALUES(1,100); とすると、Query OK, 0 rows affected (0.00 sec) と表示される。テーブルは変更されていない。 主キーと同じ値を含む行がないなら新しく挿入し、あるならその行を更新してほしいとき REPLACE INTO test VALUES(1,500); とすると、Query OK, 2 rows affected (0.00 sec)
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
OperaのXMLパーサってすごかったのね (2007-07-07)
OperaにXMLファイルを読ませるとベタテキストが出てくる。フィードだと「新規購読」というダイアログが出るけれども、画面に表示されるのは容赦ないベタテキストだ。IEやFirefoxにスタイル情報のないXMLを渡せばドキュメントツリーを表示してくれるのと対照的で、どうもOperaはXMLにやる気がないのかと勝手に思っていた。 だが、整形式でないXMLを投げた場合、Operaのエラー表示が圧倒的に見やすいことに最近気づいた。たとえば、以下のようなXMLをブラウザに表示させてみる: <?xml version="1.0" encoding="UTF-8"?> <root> <hoge>あああ</hoge> <hoge>いいい <hoge>ううう</hoge> </root>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
