Category Archives: SQLアンチパターン

「SQLアンチパターン」第28回 (2/25)

Posted on by 0 comment

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

範囲 pp.273-285

IV部 アプリケーション開発のアンチパターン

  • 24章 マジックビーンズ(魔法の豆)
    • 24.5 解決策:モデルがアクティブレコードを「持つ」ようにする
      • 24.5.2 ドメインモデルの使用 (p.273 domainmodel.phpから)
        • 「前述したサンプルコードをどのようにリファクタリングできるか」とありますが、前述したサンプルコードから処理内容が変わってしまっているところがあります。
          未定義のメンバーにアクセスしている部分がありますが、ちょっと気になります。
          サンプルコードと図24-3で整合性がとれていないところがあります。
      • 24.5.3 プレーンなオブジェクトのテスト
      • 24.5.4 現実的に考える
  • 25章 砂の城
    • 25.1 目的:サービスの安定稼働
    • 25.2 アンチパターン:想定不足
    • 25.3 アンチパターンの見つけ方
    • 25.4 アンチパターンを用いてもよい場合
    • 25.5 解決策
      • 25.5.1 ベンチマーク
      • 25.5.2 テスト環境の構築
      • 25.5.3 例外処理
      • 25.5.4 バックアップ
      • 25.5.5 高可用性
      • 25.5.6 ディザスタリカバリ
      • 25.5.7 運用ポリシーの策定

「SQLアンチパターン」第27回 (2/21)

Posted on by 0 comment

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

範囲 pp.266-273

IV部 アプリケーション開発のアンチパターン

  • 24章 マジックビーンズ(魔法の豆)
    • 24.2 アンチパターン:モデルがアクティブレコードそのもの
      • 24.2.1 アクティブレコードはモデルをデータベーススキーマに強く依存させてしまう
      • 24.2.2 アクティブレコードはCRUD機能を公開してしまう
      • 24.2.3 アクティブレコードはドメインモデル貧血症をもたらす
        • p.268 displayAction()内
          • 下から2行目の $productsTable が使用されていない。
          • $bug が参照されているだけで値が入っていない。
            2行目の $this->view->bug に代入する前に、一旦 $bug に入れているつもり?
      • 24.2.4 マジックビーンズのユニットテストは困難
    • 24.3 アンチパターンの見つけ方
    • 24.4 アンチパターンを用いても良い場合
    • 24.5 解決策:モデルがアクティブレコードを「持つ」ようにする
      • 24.5.1 モデルを理解する
      • 24.5.2 ドメインモデルの使用 (p.273 domainmodel.phpの前まで)

「SQLアンチパターン」第26回(2/18)

Posted on by 0 comment

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

IV部 アプリケーション開発のアンチパターン

  • 23章 ディプロマティック・イミュニティ(外交特権)
    • 23.5 解決策:包括的に品質問題に取り組む
      • 23.5.1 文書化(ストアドプロシージャから)
      • 23.5.2 バージョン管理
        • 囲み スキーマ進化ツール
          AddHoursToBugsのupには:decimalがあるが、downには:decimalが無いのは何故だろう?
      • 23.5.3 テスティング
        • Diplomatic_immunity/DatabaseTest.php
          コード中に出てくるassertInternalTypeは、第1引数が期待値、第2引数が実際の値、第3引数がアサーションに失敗した場合のメッセージでした。
      • 23.5.4 複数のブランチを扱う
  • 24章 マジックビーンズ(魔法の豆)
    • 24.1 目的:MVCのM(モデル)を単純化する
    • 24.2 アンチパターン:モデルがアクティブレコードそのもの

「SQLアンチパターン」第25回 (2/14)

Posted on by 0 comment

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

範囲 pp.240-255

IV部 アプリケーション開発のアンチパターン

  • 21章 シュードキー・ニートフリーク(疑似キー潔癖症)
    • 21.5.2 GUIDの使用
    • 21.5.3 最も重要な問題
  • 22章 シー・ノー・エビル(臭いものに蓋)
    • 22.1 目的:簡潔なコードを書く
    • 22.2 アンチパターン:肝心な部分を見逃す
      • 22.2.1 診断せずに判断する
      • 22.2.2 見逃しがちなコード
    • 22.3 アンチパターンの見つけ方
    • 22.4 アンチパターンを用いてもよい場合
    • 22.5 解決策:エラーから優雅に回復する
      • 22.5.1 リズムを維持する
      • 22.5.2 ステップをたどり直す
  • 23章 ディプロマティック・イミュニティ(外交特権)
    • 23.1 目的:ベストプラクティスを採用する
    • 23.2 アンチパターン:SQLを特別扱いする
    • 23.3 アンチパターンの見つけ方
    • 23.4 アンチパターンを用いてもよい場合
    • 23.5 解決策:包括的に品質問題に取り組む
      • 23.5.1 文書化(ストアドプロシージャまで)

「SQLアンチパターン」第24回 (2/7)

Posted on by 0 comment

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

範囲 pp.230-240

IV部 アプリケーション開発のアンチパターン

  • 20章 SQLインジェクション
    • 20.5 解決策:誰も信用してはならない
      • 20.5.2 動的値のパラメータ化
        • p.230 parameter.php
          account_idに対するbindValue()は、PARAM_INTになっているが、parameter.sqlでは”で括られている。値が文字列であればかってに文字列扱いになるのか。
      • 20.5.3 動的値を引用符で囲む
        • p.231 囲みに関連して
          この例では同じprepared statementを複数回使えない。複数回使うことによる利点がなくてもSQLインジェクションに対する利点だけで使うのが一般的なのだろうか。
          この本からはそのように感じ取れる。
      • 20.5.4 ユーザーの入力をコードから隔離する
      • 20.5.5 他の開発者にコードをレビューしてもらう
  • 21章 シュードキー・ニートフリーク(疑似キー潔癖症)
    • 21.1 目的:欠番を詰める
      • 21.2 アンチパターン:隙間を埋める
        • p.237 表21-3
          bug_id=4 -> 3の例だが、更新前のテーブルであろう表21-1と値が変わっているのでわかりにくい。
      • 21.2.1 欠番を割り当てる
      • 21.2.2 既存行に番号を振り直す
      • 21.2.3 データ不一致の元
    • 21.3 アンチパターンの見つけ方
    • 21.4 アンチパターンを用いてもよい場合
    • 21.5 解決策:疑似キーの欠番は埋めない
      • 21.5.1 行のナンバリング
        • p.239 中程「(例:インターネット検索サイトにおける検索結果ページ)」は、この位置より一文前の「… サブセットを返したい場合」についていたほうがわかりやすい。
        • p.239 row_number.sql
          OVERって知らなかった。MySQLには無いようだ。

「SQLアンチパターン」第23回(2/4)

Posted on by 0 comment

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

IV部 アプリケーション開発のアンチパターン

  • 20章 SQLインジェクション
    • 20.1 目的:動的SQLを記述する
    • 20.2 アンチパターン:未検証の入力をコードとして実行する
      • 20.2.1 アクシデントは起きる
      • 20.2.2 ウェブ最大のセキュリティ脅威
      • 20.2.3 対処法の追求
    • 20.3 アンチパターンの見つけ方
      • 「ルール31」:後部座席に気をつけようのカコミ内のSQL
        MATCH(カラム名) AGAINST(検索文字列)…全文検索のようです。
    • 20.4 アンチパターンを用いてもよい場合
    • 20.5 解決策:誰も信用してはならない
      • 20.5.1 入力のフィルタリング
        • PHPのfilter_input関数のマニュアルはこちら

「SQLアンチパターン」第22回 (1/31)

Posted on by 0 comment

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

範囲 pp.205-218

IV部 アプリケーション開発のアンチパターン

  • 19章 リーダブルパスワード(読み取り可能パスワード)
    • 19.1 目的:パスワードのリカバリーとリセットを行う
    • 19.2 アンチパターン:パスワードを平文で格納する
      • 19.2.1 パスワードの格納
      • 19.2.2 パスワードの認証
      • 19.2.3 パスワードを電子メールで送信する
    • 19.3 アンチパターンの見つけ方
    • 19.4 アンチパターンを用いてもよい場合
      • p.211 囲み最後 Sinsという単語の意味は?
        → 罪。七つの大罪(Seven deadly sins)からきている?
    • 19.5 解決策:ソルトを付けてパスワードハッシュを格納する
      • 19.5.1 ハッシュ関数を理解する
      • 19.5.2 SQLでのハッシュの使用
      • 19.5.3 ハッシュにソルトを加える
        • p.214 salt.sql
          • パスワードハッシュ値とソルトを一緒においておくと、そのハッシュ値を用いてパスワードを試すことが出来るのではないだろうか。p.213 dictionary-attack.sqlのような、あらかじめハッシュ値化したテーブルを使うことはできないが。
          • BINARY型はどんな型?
            非文字を含んだバイナリ列を保存できる型。
      • 19.5.4 SQLからパスワードを隠す
      • 19.5.5 パスワードをリカバリーするのではなく、リセットする

「SQLアンチパターン」第21回(1/28)

Posted on by 0 comment

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

III部 クエリのアンチパターン

  • 17章 スパゲッティクエリ
    • 17.5 解決策:分割統治を行う
      • 17.5.2 UNIONを用いる
        • LEFT OUTER JOIN
          OUTERは省略できる
        • UNION ALL
          ALLをつけないと重複レコードは削除される
      • 17.5.3 CASE式とSUM関数を組み合わせる
      • 17.5.4 上司の問題を解決する
        • 処理をアトミックに行っていないので、数字がずれる可能性がある。
        • 冒頭のエピソードの例ではそれほど厳密でなくてよいだろうから分割処理でも大丈夫だろう。
      • 17.5.5 SQLを用いたSQLの自動的な記述
        • 囲み 複数のUPDATEステートメント生成
          SQLの1行目の末尾のカンマが抜けている
  • 18章 インプリシットカラム(暗黙の列)
    • 18.1 目的:タイプ数を減らす
    • 18.2 アンチパターン:ショートカットの罠に陥る
      • 18.2.1 リファクタリングにおける問題
      • 18.2.2 隠れた代償
      • 18.2.3 求めなければ得られない
    • 18.3 アンチパターンの見つけ方
    • 18.4 アンチパターンを用いてもよい場合
    • 18.5 解決策:列名を明示的に指定する
      • 18.5.1 誤りの防止
      • 18.5.2 それは多分、必要ない(YAGNI:You Ain’t Gonna Need It)
      • 18.5.3 ワイルドカードを使えない局面はいずれ訪れる

「SQLアンチパターン」第20回 (1/24)

Posted on by 0 comment

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

範囲 pp.181-192

III部 クエリのアンチパターン

  • 16章 プアマンズ・サーチエンジン(貧者のサーチエンジン)
    • 16.5 解決策:適切なツールを使用する
      • 16.5.7 サードパーティーのサーチエンジン (p.181 spinx.confから)
        • search -b “crash -save”の-bは Boolean マッチングモードにするオプション。
        • p.183 l.8 誤植:「検索対象になりる可能性」→「検索対象になり得る可能性」
        • 検索対象が日本語の場合は、わかち書きが必要です。
  • 17章 スパゲッティクエリ
    • 17.1 目的:SQLクエリの数を減らす
    • 17.2 アンチパターン:複雑な問題をワンステップで解決しようとする
      • 17.2.1 意図に反した結果
      • 17.2.2 さらなる弊害
    • 17.3 アンチパターンの見つけ方
    • 17.4 アンチパターンを用いてもよい場合
    • 17.5 解決策:分割統治を行う
      • 17.5.1 ワンステップずつ

「SQLアンチパターン」第19回 (1/21)

Posted on by 0 comment

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

範囲 pp.173-181

III部 クエリのアンチパターン

  • 16章 プアマンズ・サーチエンジン(貧者のサーチエンジン)
    • 16.1 目的:全文検索を行う
    • 16.2 アンチパターン:パターンマッチ述語を使用する
    • 16.3 アンチパタンの見つけ方
    • 16.4 アンチパターンを用いてもよい場合
    • 16.5 解決策:適切なツールを使用する
      • 16.5.1 ベンダー拡張
      • 16.5.2 MySQLのフルテキストインデックス
        • p.176 MySQLにこの機能があることは知らなかった。
        • p.176 match-boolean.sql内 ‘IN BOOLEAN MODE’とは何?
          • ここの例にある’+’や’-‘などの演算子を使って論理式の検索式をつかって検索するモード。演算子は’+’, ‘-‘以外にもいろいろある。
          • Booleanフルテキスト検索モードのほかに、Natural laguageフルテキスト検索モードもある。(Ref. MySQL 5.6 Reference Manual 12.9. Full-Text Search Functions)
      • 16.5.3 Oracleでのテキストインデックス
        • p.177 ctxcat-search.sql
          ‘(crash save)’はcrashもsaveも含む行になり、文法としてはあっているのだろうが、他のDBMSの例(crashは含むがsaveは含まない行)と異なる。
        • 他のDBMSも含めて、これらの検索に日本語は使えるのだろうか? だめそうだけど。
          → MySQLはMroongaというMySQL用ストレージエンジンを使えばできるようだ。
      • 16.5.4 Microsoft SQL Serverでの全文検索
        • p.178 create-index.sql
          説明が簡単すぎて例の意味がわからない。’2057’って何?
      • 16.5.5 PostgreSQLでのテキスト検索
      • 16.5.6 SQLiteでの全文検索(FTS)
      • 16.5.7 サードパーティーのサーチエンジン (p.181 spinx.confの前まで)