回答編集履歴
2
スペルミス修正
answer
CHANGED
|
@@ -19,7 +19,7 @@
|
|
|
19
19
|
ここからは、質問いただいたのでしかたなく（ちょっと私のビジネスのコアコンピタンスに触れそう・・・）
|
|
20
20
|
まず、技術的にはレコードのIDを生成する方法について考える必要があります。外部キーに使うIDなので当然一意のものを生成する必要がありますが社員番号など業務上のIDとは別に生成する必要があります。このIDの生成について2案あります。
|
|
21
21
|
- UUID(RFC4122)を使う→分散環境でも確実に一意のIDを生成することができ、ロックマネージャなどにお伺いを建てなくても生成できるメリットが有ります
|
|
22
|
-
- 更新毎に文脈通番＝CSN(
|
|
22
|
+
- 更新毎に文脈通番＝CSN(Context Sequencial Number) を振り出すこととし、すべての更新処理においては、まず、通番を取得し、この通番に1回の更新内の連番を追加した番号を使います→CSNマネージャンという番号を振り出すサービスが必要であるが、更新の前後関係を CSN の大小で比較できるメリットが得られる
|
|
23
23
|
|
|
24
24
|
そして、前述したように、データベースをどう実装するか以前に、システム間連携の API/SPI の仕様の問題となります。社員マスタシステムに関しては、従来であれば、社員マスタシステムに対する問い合わせ処理をAPIで実装するだけでよかったのですが、更新削除なし設計では、更新通知を受け取る SPI (Service Proveider Interface)を実装する必要があります。（すいません、詳細省略）
|
|
25
25
|
|
1
実装方法に関する記述を追加
answer
CHANGED
|
@@ -13,4 +13,14 @@
|
|
|
13
13
|
|
|
14
14
|
こんどはデメリットになるケースを考えてみましょう。利用者毎に自分と親しい社員だけを登録するアドレス帳のアプリを考えてみましょう。アドレス帳レコードは社員レコードへの外部キーだけを持てばよいでしょう。従来型のデータベース設計であれば、SELECT JOIN で常に最新のデータが取れるので問題ありません。しかし、更新削除なし設計の場合は、社員マスタが更新される毎にアドレス帳レコードを更新する必要があります。アドレス帳のアプリは、常に社員マスタの更新通知を受け取って必要に応じてアドレス帳を保守する必要があるわけです。
|
|
15
15
|
|
|
16
|
-
更新削除なし設計だと、あきらかにシステム間の結合度が上がって不利なようにみえますが、いや、そんなアプリのほうが少ないだろ！っていうのが CRUD is Dead ってことかなって思いました
|
|
16
|
+
更新削除なし設計だと、あきらかにシステム間の結合度が上がって不利なようにみえますが、いや、そんなアプリのほうが少ないだろ！っていうのが CRUD is Dead ってことかなって思いました
|
|
17
|
+
|
|
18
|
+
**技術的解説**
|
|
19
|
+
ここからは、質問いただいたのでしかたなく（ちょっと私のビジネスのコアコンピタンスに触れそう・・・）
|
|
20
|
+
まず、技術的にはレコードのIDを生成する方法について考える必要があります。外部キーに使うIDなので当然一意のものを生成する必要がありますが社員番号など業務上のIDとは別に生成する必要があります。このIDの生成について2案あります。
|
|
21
|
+
- UUID(RFC4122)を使う→分散環境でも確実に一意のIDを生成することができ、ロックマネージャなどにお伺いを建てなくても生成できるメリットが有ります
|
|
22
|
+
- 更新毎に文脈通番＝CSN(Contest Sequencial Number) を振り出すこととし、すべての更新処理においては、まず、通番を取得し、この通番に1回の更新内の連番を追加した番号を使います→CSNマネージャンという番号を振り出すサービスが必要であるが、更新の前後関係を CSN の大小で比較できるメリットが得られる
|
|
23
|
+
|
|
24
|
+
そして、前述したように、データベースをどう実装するか以前に、システム間連携の API/SPI の仕様の問題となります。社員マスタシステムに関しては、従来であれば、社員マスタシステムに対する問い合わせ処理をAPIで実装するだけでよかったのですが、更新削除なし設計では、更新通知を受け取る SPI (Service Proveider Interface)を実装する必要があります。（すいません、詳細省略）
|
|
25
|
+
|
|
26
|
+
つまり、更新削除なし設計については、データベースのスキーマ設計以前にシステム間連携の API/SPI の仕様の問題であると思います（たとえ、それが CSV+FTP の実装であっても）。実際に更新削除をしないデータベースをMySQL などの RDBMS 上に実装しようとすると、それなりに性能問題に対する技工が必要です。それこそ、みなさんの出番です(^_^)
|