タグ

ブックマーク / torazuka.hatenablog.com (7)

  • メモ: 複合主キーを云々いう前に足りなかったこと - 虎塚

    先日、データベース設計で、ナチュラルキーの組合せを使った複合主キーと、その代替となるサロゲートキーのどちらを使うか、という話を書きました。 複合主キーを避けるべき理由 - 虎塚 月末までには、改めて考えを整理するつもりでした。しかし、残念ながら、今の自分の知識ではムリそうです。そこで、考えたことを少しずつ出力することにしました。 この問題について考えるべき(だった)こと 前回の記事に足りなかった観点が3つあります。 データベースの論理設計と物理設計を分ける 複数ある要素の一部にだけ言及していると自覚する すべては程度問題である これらを1つずつ考えてみます。 1. 論理設計と物理設計を分ける まず、データベースの論理設計と物理設計を分けて考える必要がありました。非常に、基的なことですが・・・ 論理設計で、ユニーク制約が必要なキーと、行を一意に特定するキー(候補キー)を特定します。もちろん

    メモ: 複合主キーを云々いう前に足りなかったこと - 虎塚
  • JJUG CCC 2013 Fall「JVMコードリーディング入門」資料公開 - 虎塚

    土曜にJJUG CCC 2013 Fall(http://www.java-users.jp/?page_id=695)へ行ってきました。 事前にお知らせするのを忘れていましたが、17:15〜18:05のセッションでJVMのソースコードリーディングについてお話ししましたので、発表資料を公開します。 R5-5 JVMコードリーディング入門 〜JVMのOS抽象化レイヤーについて〜 JVMのコードを読みはじめたばかりの方を対象に、JVMとOSのメモリを中心とした関係性についてお話しします。JVMはOSからどのようにメモリを確保しているのでしょうか? そんな素朴な疑問をもとに、JVMのコードを楽しく追いかけてみましょう。※このセッションは入門者向けです。バイトコードやGCについては扱いません。 虎塚 (さくらば組) http://www.java-users.jp/?page_id=709#r5-

    JJUG CCC 2013 Fall「JVMコードリーディング入門」資料公開 - 虎塚
  • インクリメント in ローカル変数、インスタンス変数、クラス変数の違い - 虎塚

    Javaの前置インクリメントと後置インクリメントの内部実装を読みたい - 虎塚 Javaの前置・後置インクリメントの内部実装を読みたい・その2 - 虎塚 id:terazzoさんのブコメのおかげで、ひとまず、前置/後置インクリメント命令を定数化した箇所を見つけました。ありがとうございます。 {OpenJDK6_dir}/langtools/src/share/classes/com/sun/tools/javac/tree以下のJCTree.java(268〜275行目付近)にありました。 が、構文木の詳細はまだ追えていません。この週末はだらけていて、気づいたらこんなカンジでした。 今日は、同じインクリメントに関するテーマですが、別の話です。 『Java仮想マシン仕様』の演算子に関する解説を眺めていたら、気になることが書かれていました。 3.11.3「算術命令」に、次の記述があります。 ロ

    インクリメント in ローカル変数、インスタンス変数、クラス変数の違い - 虎塚
  • クラウドアーキテクチャパターン(via DoubleCloud.org) - 虎塚

    調べ物をしていて、Cloud Architecture Patternsなるものに辿り着きました。 次の記事が、パターンに関する概要です。 Cloud Architecture Patterns: Overview http://www.doublecloud.org/2010/10/cloud-architecture-patterns-overview/ 別記事で、10個のパターンが解説されています。 ブログ記事ではありますが、アレグザンダーの『パターン・ランゲージ』や、それにインスパイアされて書かれた(いわゆる)パターンの形式が、ほぼ踏襲されています。 Motivation: そのパターンを適用する前提や課題 Solution: Motivationに対する解決策 Applicability: パターンがどのように適用するか Consequence: パターンを活用した結果 Kno

    クラウドアーキテクチャパターン(via DoubleCloud.org) - 虎塚
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
  • デフォルトのシリアルバージョンUIDを作成するコードを読んでみる - 虎塚

    ダイチャンさんが、ブログでJavaのシリアルバージョンUIDの話をされていて、最後の一文が自分も気になったので調べました。 ランタイムが未定義のserialVersionUIDにどんな値を割り当ててるのか、見る方法は分からなかった。誰か知ってますか? SerializableとserialVersionUID - 都元ダイスケ IT-PRESS 元記事のコメントにnobeansさんが書いてくださったとおり、読むべきコードはこちら。 実装 {jdk-6u23-jr}/j2se/src/share/classes/java/io/ObjectStreamClass.java Javadoc Oracle Technology Network for Java Developers | Oracle Technology Network | Oracle ドキュメントに計算の内容まで相当詳細に書

    デフォルトのシリアルバージョンUIDを作成するコードを読んでみる - 虎塚
  • JDKの時間計測まわりのコードを読んでみる - 虎塚

    ぐぬぬ。。。せっかくのご指名ですが。。。 JVMがOSごとにどの計時関数を呼び出すのかすら、自分はろくに知らないのです…無念だ。 でも、「ネタを振られたら全力で撃ち返せ」ってじっちゃが言ってた。 というわけで、最適化よりもずっと手前の話題、JVMの時間取得まわりのコードを眺めてみようと思います。 Systemクラスのソースコードを見ると public static native long currentTimeMillis(); と、native宣言されている。ここから先はネイティブの世界。VMの実装依存の世界でもある。 Javaパフォーマンス計測 そんなタイマーで大丈夫か? - プログラマーの脳みそ そですね。では、その世界を確認してみましょう。 ゴール Javaで時間計測を行った時に各OSで最終的に呼ばれるAPIとその精度について、JDKのソースコードおよびドキュメントを元に把握する。

    JDKの時間計測まわりのコードを読んでみる - 虎塚
  • 1