ゼロの使い魔 18 滅亡の精霊石

ゼロの使い魔 18 滅亡の精霊石
ゼロの使い魔 18 滅亡の精霊石
posted with amazlet at 10.01.24
ヤマグチ ノボル
メディアファクトリー
売り上げランキング: 3
おすすめ度の平均: 5.0
5 ヤマグチノボルの暴走
5 想い新たに
Amazon.co.jp で詳細を見る



滅亡するらしい（何が？）
さておき、既にアレと化してきた。
そろそろＲ－１５とかつけた方が良くないそうでもない？
 
さておき（2回目）前と比べて薄くなった？
何か3時間程度で読みきったんだけど、薄くなった？
値段変わらずなのはデフレのせい？
業界よく分からん。

コメント

コメントを投稿

このブログの人気の投稿

ResultSet.next()の高速化

defaultRowPrefetch?のサイズを変更することにより、格段にパフォーマンスが上がるそうです。大量のデータをDBから取得する際に有効と思われます。 以下原文 以下の記述でみごと解決致しました。 java.util.Properties info = new java.util.Properties(); info.put("user", "scott"); info.put("password", "tiger"); info.put("defaultRowPrefetch", "100"); Connection conn=DriverManager.getConnection("jdbc:oracle:thin:@ホスト名:1521:テーブル名", info); プリフェッチのサイズはDefaultで10だそうで、 とりあえず100にしただけで、1万件あたり約3.5分が わずか3秒になってしまいました。 本当にどうもありがとうございました。
Read more »

Pro*c的にはUPDATEとかDELETE0件はエラー

Pro*C的には（というか、Oracle的？）には0件DELETEやUPDATEはOracleエラーだそうです。 「ora-1403」が返ってきてアプリ落ちました。 んで、DELETEとUPDATEのエラーハンドリングで1403を捕まえて無視するように修正予定。 てか、JDBCだと落ちなかった気がするけど、きっとJDBCが無視してくれてるんだよね、と信じてます。 > 1403は正の値なので例外にはなりませんね。例外は負の値の場合です。 Pro*C的には正の値こそが例外なんですよ。そして、負の値はエラー。 > 確実なのは件数取得でしょうかね。 これは好きな方法ではありません。 SELECT count(*)実行後、INSERTを実行するまでのわずかなタイミングで、他のトランザクションに先を越される可能性がゼロではないですから。そうすると、結局INSERTでORA-1が発生する可能性を考慮しなくてはならず、そんだったら最初っから何も考えずにINSERTすればいいじゃん、となります。 また、件数で判定するとしたら、SELECT count(*)などせずに、まずUPDATEを実行し、その更新レコード数を取得するほうが、手順が少なく済む＝割り込まれる可能性が低くなります。 なので、自分的にはINSERT→UPDATEか、UPDATE→INSERTのどちらかなのですが、どっちを選ぶかは「INSERTとUPDATEのどちらが成功する可能性が高いか」で決めます。これは業務に依存するはなしです。
Read more »

雁尾千恵（３７）

イメージ
雁尾千恵（３７）が自殺したかどうかは知らんよ。 てか、雁尾千恵ってどんな人かも知らん。 前々から気になってたんだけど、これって本当？ヤラセ？ 本当にいるの？てか、実名入りで全国区で放送って、大分勇気いるよね？ コラージュ？
Read more »