1. RDBをやめ, テキストにする
1.1. ユニケージ開発手法の考え方
1.2. インピーダンスミスマッチ
1.2.1. ある
1.2.1.1. RDB とオブジェクトの間
1.2.2. ない
1.2.2.1. テキストファイルとフィルタ (関数型)
2. テーブル構成から自由になれるか?
2.1. テーブル構成の変更にコードは付いてくるか?
2.2. 変更に付いて来なくても良い方法はあるか?
2.2.1. XML-DB が良いかも
2.2.1.1. XML-DBの基本操作とその仕組み (ウルシステムズ)
2.2.1.2. 非定形フォーマット
2.2.1.2.1. スキーマ定義が必要ない
2.2.1.2.2. フィールドが自由に増やせる
2.2.1.3. XML なので複数のプログラミング言語や環境から使える
2.2.1.3.1. オブジェクト DB だとライブラリサポートが必要
3. 基本的にはNullを排除すべき
3.1. 資料
3.1.1. NULL撲滅委員会
3.1.2. 連載! とことん C#: 第 7 回 null を受け入れるか? 排除するか? (null 許容型と null 合体演算子)
3.1.3. NULLは諸悪の根源｜システム開発のアイロベックス
3.1.4. データベースにNULLを入れてはいけない5つの理由: mitsuruogの日記
3.2. 理由
3.2.1. Nullが入ると直感に反する演算結果になるから
3.2.2. 利用側でNullを考慮したコードにする必要があるから
3.3. 代替方法
3.3.1. フィールドを別テーブルに分ける
3.3.1.1. 正規化
3.3.1.1.1. T字型ER
3.3.2. 特定の値にする
3.3.3. Nullオブジェクトを使用する
4. DB のレコードと O/R マッピング
4.1. 普通は O/R マッピング
4.2. レコードをそのままリストとして関数型で処理すると良さそう
4.2.1. レコード → オブジェクトの 転記量が 増える
4.2.2. Play2.0 の Anorm が この 考え方に なっている
5. DB を 不要に できる?
5.1. CQRS の考え方
5.1.1. Event Sourcing
5.1.2. ドメインモデルを オンメモリに 置く
5.1.3. DB は レポートの ソースとする
5.1.3.1. = キャッシュ?
5.1.3.2. JSON ファイルでも よい?
5.1.4. 別マップ: コマンド クエリ 責務分離 | CQRS
6. DB の データーは すべて テキストに 落とせるべき
6.1. 比較できる
6.1.1. DB 間
6.1.2. ある 時点での 状態
6.2. 加工して 他システムの Event Source として 使える
7. Microsoft Access
7.1. Access のレコードにロジックを持たせる方法
7.1.1. 1. テーブルごとに対応するフォームを作成する
7.1.1.1. 連結させる
7.1.2. 2. フォームにロジックを組み込む
7.1.3. 3. フォームを開き、処理を呼び出し、閉じる
7.2. フォームの レコードソース
7.2.1. 抽出する 場合
7.2.1.1. テンポラリ テーブルを 作成する
7.2.1.1.1. フィールド
7.2.2. 修正する 場合
7.2.2.1. テンポラリ テーブルを 作成する
7.2.2.1.1. フィールド
7.2.2.2. 再クエリーや フォームを 閉じる タイミングで データーを テーブルに 書き戻す
7.2.3. 抽出, 修正しない 場合
7.2.3.1. クエリー 直結
7.3. テーブル, クエリー, フォーム (レポート) を メンテナンスしやすく したい
7.3.1. 規則を 持たせる
7.3.1.1. 命名
7.3.1.2. 機能 分割
7.3.2. MVC の 考え方を 取り入れたら どうなる?
7.3.3. Access で フォームに 関連のある クエリー
7.3.3.1. 共有する
7.3.3.1.1. 1 つの 修正が 複数の フォームに 影響する
7.3.3.2. 複製して 使う
7.3.3.2.1. フォームごとの 修正が やりやすい
7.3.3.2.2. 同じ 修正を する には すべてに 同じ 修正を しなければ ならない
7.4. 欠点
7.4.1. テーブルを直接操作できる
7.4.1.1. ユーザーが全レコードを消せる
7.4.2. 修正点、差分を管理しにくい
7.4.2.1. ソースやオブジェクト
7.4.2.2. レコードの更新情報
7.5. データーメンテナンス用途で使うとよい
7.5.1. Webシステム用DBデーターの保守など
8. 別マップ: Event Sourcing
8.1. Event Sourcing は DBMS の 変更に 強い
9. アイデンティティフィールドは 指定の 値を 入れられるように すべき
9.1. テストデーターを入れやすい
9.2. ビジネスロジックが付番する
9.3. DB の 構造変更に 強くなる
10. DB 名, フィールド名の日本語
10.1. PowerNews 316号アンケート結果 - PowerNews関連記事 ｜ GrapeCity Developer Tools
10.1.1. 2010.11 ～ 12 のアンケート結果
10.1.1.1. SQL Server や Oracle 利用者に偏っている?
10.1.2. 排除する派
10.1.2.1. 理由
10.1.2.1.1. 外国とのやりとりで困る
10.1.2.1.2. ソースに日本語が入るのが嫌
10.1.2.1.3. 操作時に IME オン・オフが煩わしい
10.1.2.1.4. ツールが日本語 (MBCS) を考慮していない場合がある
10.1.2.1.5. DB 間の移植性
10.1.2.1.6. 不安がある
10.1.2.1.7. トラブルを未然に防ぐ
10.1.2.2. 代替方法
10.1.2.2.1. 英語にする
10.1.2.2.2. ヘボン式ローマ字にする
10.1.3. 使用する派
10.1.3.1. 理由
10.1.3.1.1. すべての層で同じ名前を使うべき
10.1.3.1.2. 意図がわかりやすい
10.1.3.1.3. コメントを削減できる
10.1.3.1.4. 英語にすると
10.1.3.1.5. 顧客がデーターを使いやすい
10.1.3.1.6. ソースコード中で名前と予約語が判別しやすい
11. RDB に入れるには小さいデーターがある
11.1. 単一レコードで済むもの
11.1.1. アプリのウィンドウジオメトリ情報
11.1.2. デフォルトユーザー名, デフォルト税率等
12. RDB と XML / JSON 型の折衷案
12.1. RDB を使うがフィールドを固定しない方法
12.2. キーとなるフィールドだけ用意する
12.3. テキストフィールドを用意し, XML / JSON をそのまま入れる
12.4. あとで運用上必要になった時にフィールドを作り, XML / JSON からデーターを入れる
13. ロストアップデートへの対応
13.1. 同時に同じレコードを修正してしまう問題
13.1.1. データベースの不整合（ロストアップデート）と戦おう！
13.2. 対応策
13.2.1. WHERE 句に元の値を入れて比較する, 行バージョニング