Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Persistence 層, DB に関するアイデア by Mind Map: Persistence 層, DB に関するアイデア
0.0 stars - reviews range from 0 to 5

Persistence 層, DB に関するアイデア

RDBをやめ, テキストにする

ユニケージ開発手法の考え方

インピーダンスミスマッチ

ある, RDB とオブジェクトの間

ない, テキストファイルとフィルタ (関数型)

テーブル構成から自由になれるか?

テーブル構成の変更にコードは付いてくるか?

変更に付いて来なくても良い方法はあるか?

XML-DB が良いかも, XML-DBの基本操作とその仕組み (ウルシステムズ), 非定形フォーマット, スキーマ定義が必要ない, フィールドが自由に増やせる, XML なので複数のプログラミング言語や環境から使える, オブジェクト DB だとライブラリサポートが必要

基本的にはNullを排除すべき

資料

NULL撲滅委員会

連載! とことん C#: 第 7 回 null を受け入れるか? 排除するか? (null 許容型と null 合体演算子)

NULLは諸悪の根源|システム開発のアイロベックス

データベースにNULLを入れてはいけない5つの理由: mitsuruogの日記

理由

Nullが入ると直感に反する演算結果になるから

利用側でNullを考慮したコードにする必要があるから

代替方法

フィールドを別テーブルに分ける, 正規化, T字型ER

特定の値にする

Nullオブジェクトを使用する

DB のレコードと O/R マッピング

普通は O/R マッピング

レコードをそのままリストとして関数型で処理すると良さそう

レコード → オブジェクトの 転記量が 増える

Play2.0 の Anorm が この 考え方に なっている

DB を 不要に できる?

CQRS の考え方

Event Sourcing

ドメインモデルを オンメモリに 置く

DB は レポートの ソースとする, = キャッシュ?, JSON ファイルでも よい?

別マップ: コマンド クエリ 責務分離 | CQRS

DB の データーは すべて テキストに 落とせるべき

比較できる

DB 間

ある 時点での 状態

加工して 他システムの Event Source として 使える

Microsoft Access

Access のレコードにロジックを持たせる方法

1. テーブルごとに対応するフォームを作成する, 連結させる

2. フォームにロジックを組み込む

3. フォームを開き、処理を呼び出し、閉じる

フォームの レコードソース

抽出する 場合, テンポラリ テーブルを 作成する, フィールド, 抽出後の 主キー

修正する 場合, テンポラリ テーブルを 作成する, フィールド, フォーム上で 変更する フィールド, データー修正 しない フィールドは 作成しない, クエリーと JOIN して 表示する, 再クエリーや フォームを 閉じる タイミングで データーを テーブルに 書き戻す

抽出, 修正しない 場合, クエリー 直結

テーブル, クエリー, フォーム (レポート) を メンテナンスしやすく したい

規則を 持たせる, 命名, 機能 分割

MVC の 考え方を 取り入れたら どうなる?

Access で フォームに 関連のある クエリー, 共有する, 1 つの 修正が 複数の フォームに 影響する, エンバグの 可能性, 複製して 使う, フォームごとの 修正が やりやすい, 同じ 修正を する には すべてに 同じ 修正を しなければ ならない

欠点

テーブルを直接操作できる, ユーザーが全レコードを消せる

修正点、差分を管理しにくい, ソースやオブジェクト, レコードの更新情報

データーメンテナンス用途で使うとよい

Webシステム用DBデーターの保守など

別マップ: Event Sourcing

Event Sourcing は DBMS の 変更に 強い

アイデンティティフィールドは 指定の 値を 入れられるように すべき

テストデーターを入れやすい

ビジネスロジックが付番する

DB の 構造変更に 強くなる

DB 名, フィールド名の日本語

PowerNews 316号アンケート結果 - PowerNews関連記事 | GrapeCity Developer Tools

2010.11 ~ 12 のアンケート結果, SQL Server や Oracle 利用者に偏っている?

排除する派, 理由, 外国とのやりとりで困る, ソースに日本語が入るのが嫌, 視認性が悪い, インテリセンスが効かない, 操作時に IME オン・オフが煩わしい, ツールが日本語 (MBCS) を考慮していない場合がある, DB 間の移植性, 不安がある, トラブルを未然に防ぐ, 代替方法, 英語にする, ヘボン式ローマ字にする

使用する派, 理由, すべての層で同じ名前を使うべき, 意図がわかりやすい, コメントを削減できる, 英語にすると, ニュアンスが変わる, 対応表が必要になる, 訳が, 間違っている場合がある, 開発者によってバラつく, 顧客がデーターを使いやすい, ソースコード中で名前と予約語が判別しやすい

RDB に入れるには小さいデーターがある

単一レコードで済むもの

アプリのウィンドウジオメトリ情報

デフォルトユーザー名, デフォルト税率等

RDB と XML / JSON 型の折衷案

RDB を使うがフィールドを固定しない方法

キーとなるフィールドだけ用意する

テキストフィールドを用意し, XML / JSON をそのまま入れる

あとで運用上必要になった時にフィールドを作り, XML / JSON からデーターを入れる

ロストアップデートへの対応

同時に同じレコードを修正してしまう問題

データベースの不整合(ロストアップデート)と戦おう!

対応策

WHERE 句に元の値を入れて比較する, 行バージョニング

ユニケージや CQRS ならば対応不要 ?