Monthly Archives: 11月 2013

「SQLアンチパターン」第6回 (11/29)

参加者 今井(読み手)、青木、沼田(記)
範囲 pp.26 – 35

I部 データベース論理設計のアンチパターン

  • 第2章 ナイーブツリー(素朴な木)
    • 2.5 解決策:代替ツリーモデルを使用する
      • 2.5.3 閉包テーブル(Closure Table)
        • Trees/soln/closure-table/insert.sql
          INSERT文のUNION ALLの前後のSQLが、説明と逆になっている。何か理由がある?
        • Trees/soln/closure-table/delete-subtree.sql
          UPDATE同様、DELETEの場合も削除対象のテーブルをサブクエリに書けないので一時テーブルxを作っているのだろう。
        • p.30 path_length属性を追加した場合、INSERTが大変になるのでは?
      • 2.5.4 どの設計を使うべきか
        • どの設計を採用するかを判断するには、表2-5に、実行速度の視点や向き・不向きが欲しい。
  • 第3章 IDリクワイアド(とりあえずID)
    • 3.1 目的:主キーの規約を確立する
      • p.33
        SQLのファイル名が一緒
      • p.33 COUNT(*)で件数を数えているが、COUNT(列名)との違いは?
        →指定した列の値がNULLの場合は件数に含まれなくなるようです。

「SQLアンチパターン」第5回 (11/26)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 pp.20-26

I部 データベース論理設計のアンチパターン

  • 2章 ナイーブツリー(素朴な木)
    • 2.5 解決策:代替ツリーモデルを使用する
      • 2.5.1 経路列挙(Path Enumeration)
        p.21 Trees/soln/path-enum/ancestors.sql
        「’1/4/6/7′ LIKE c.path || ‘%’」のようにリテラルをLIKEの左側に記述したことはありませんでした。このように書けるのですね。
      • 2.5.2 入れ子集合(Nested Set)

「SQLアンチパターン」第4回 (11/22)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 pp.7-20

I部 データベース論理設計のアンチパターン

  • 1章 ジェイウォーク(信号無視)
    • 1.3 アンチパターンの見つけ方
    • 1.4 アンチパターンを用いてもよい場合
    • 1.5 解決策:交差テーブルを作成する
      • 1.5.1 特定のアカウントに関連する製品の検索/特定の製品に関連するアカウントの検索
      • 1.5.2 集約クエリの作成
      • 1.5.3 製品の連絡先の更新
      • 1.5.4 製品IDの妥当性検証
      • 1.5.5 区切り文字の選択
        • p.11 「カンマ区切りと同じ文字が」は、「区切り文字と同じ文字が」の意味だろう。
      • 1.5.6 リストの長さの制限
      • 1.5.7 交差テーブルの他のメリット
  • 2章 ナイーブツリー(素朴な木)
    • 2.1 目的:階層構造を格納し、クエリを実行する
    • 2.2 アンチパターン:常に親のみに依存する
      • 2.2.1 隣接リストへのクエリ実行
      • 2.2.2 隣接リストのツリーのメンテナンス
    • 2.3 アンチパターンの見つけ方
    • 2.4 アンチパターンを用いても良い場合
      • p.19
        cte.sqlとconnect-by.sqlであれば、connect-by.sqlの方が直接的でわかりやすいですね。

「SQLアンチパターン」第3回 (11/19)

参加者 今井(読み手)、青木、沼田(記)
範囲 pp.295 – 301、pp.1 – 7

V部 付録

  • A.正規化のルール
    • A.3 正規化とは何か
      • A.3.3 第3正規形
      • A.3.4 ボイスコッド正規形
      • A.3.5 第4正規形
        • 例えばBusgVerifiedは第4正規形にすれば1レコードですむ
      • A.3.6 第5正規形
      • A.3.7 他の正規形
    • A.4 正規化は常識的なもの

I部 データベース論理設計のアンチパターン

  • 1章 ジェイウォーク(信号無視)
    • 1.1 目的:複数の値を持つ属性を格納する
    • 1.2 アンチパターン:カンマ区切りフォーマットのリストを格納する
      • 1.2.1 特定のアカウントに関連する製品の検索
        • [[:<:]]と[[:>:]]
          MySQL5.1のマニュアルによると、語の最初と最後それぞれにマッチする表現でした。
      • 1.2.2 特定の製品に関連するアカウントの検索
      • 1.2.3 集約クエリの作成
      • 1.2.4 特定の製品に関連するアカウントの更新
      • 1.2.5 製品IDの妥当性検証
      • 1.2.6 区切り文字の選択
      • 1.2.7 リストの長さの制限

「SQLアンチパターン」第2回 (11/15)

Posted on by 0 comment

参加者 沼田(読み手)、今井(記)

範囲 pp.xix-xxxv, pp.287-295

  • はじめに
    • 表記ルール
      • フォント
      • 用語
      • ER図
    • サンプルデータベース
      • p.xxi 図1
        • 多対多の中央のテーブルは、”関連テーブル”ではなく”交差テーブル”と言うのですね。
        • OOでクラス名を単数形にするように自分たちはテーブル名も単数形にしていたが、この本では複数形にするようだ。本文で理由がでてくるかな。
        • この書き方はアナリシスパターンでも使われていた。○<で0以上、||で1~1の意味。(Odellノーテーションと言うらしいです。)
      • p.xxi 下のSQLにあるSERIALって何?
        ‘BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE’の別名らしい。
      • p.xxii CREATE TABLE Bugs
        bud_idのSERIALのインデントがそろっていない
    • 意見と質問
    • 謝辞
  • 目次

V部 付録

  • 付録A 正規化のルール
    • A.1 リレーショナルとは何か
      • A.1.1 行に上下の順番がない
      • A.1.2 列に左右の順番がない
      • A.1.3 重複行をきょかしない
      • A.1.4 すべての列は1つの型を持ち、各行に1つの値を持つ
        • p.291 A.1.5の前 衍字
          値1234と同じものものであるとは
      • A.1.5 行に隠されたコンポーネントがない
    • A.2 正規化の神話
    • A.3 正規化とは何か
      • A.3.1 第1正規形
      • A.3.2 第2正規形

「SQLアンチパターン」第1回 (11/12)

Posted on by 0 comment

参加者 今井(読み手)、青木(記)

範囲 巻末, 巻頭, pp.v-xix

巻末

  • 著者紹介
  • 監訳者紹介
  • 訳者紹介

巻頭

  • 本書への称賛の声
  • 監訳者まえがき
    • 和田卓人によるまえがき
    • 和田省二によるまえがき
  • はじめに
    • 対象読者
    • 対象範囲
    • 本書の構成
    • 各章の構成-アンチパターンの「解剖」
    • 本書の対象範囲ではないもの

「インタフェースデザインの実践教室」第19回 (11/7)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 pp.291-301

III部 インプリメンテーション

34章 利用データの収集

  • 34.1 速度の測定
  • 34.2 出口点
  • 34.3 不具合の記録
  • 34.4 ユーザーの行動
  • ポイント
  • 参考文献

35章 ユーザーからのフィードバック

  • 35.1 思いもよらない使われ方
  • 35.2 たちの悪いフィードバック
  • ポイント

最後に—でも、まだ終わってはいません

訳者あとがき

 

読了

 

「インタフェースデザインの実践教室」第18回 (11/5)

Posted on by 0 comment

参加者 今井(読み手)、沼田(記)
範囲 pp.271 – 290

III部 インプリメンテーション

31章 ユーザビリティテスト「べからず集」

  • 31.1 ユーザーインタフェースに表示される語句は使わない
  • 31.2 テスターに影響を与えない
    • l.1
      オーステン(脱字)
  • 31.3 ストレスのかかる状況を避ける

32章 ユーザーエラーはデザインエラー

  • 32.1 エラーメッセージでユーザーを責めない
    • 人はバカにされることを好まない
      dolt(DOLT)と読んでしまったようです
  • 32.2 エラーをなくす

33章 A/Bテスト

  • 概要の7行目
    …ユーザーにとってどちら便利か…→どちら便利か
  • 33.1 いつA/Bテストを行うか
  • 33.2 成功とは何か?
  • 33.3 テストの準備
  • 33.4 テストの実施
  • 33.5 テスト結果の解釈
  • 33.6 留意点