質問編集履歴
1
引用元の訂正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
DBMSのトランザクション分離レベル（DBMSによって異なる）とプログラムは影響を受けるのでしょうか？
|
|
2
2
|
|
|
3
|
-
「達人に学ぶDB設計徹底指南書」という本を読んでいます。
|
|
3
|
+
「達人に学ぶDB設計徹底指南書」（2012年、ミック著）のという本を読んでいます。
|
|
4
4
|
|
|
5
|
-
次のような文章がありました。オートナンバリングの実現方法としてアプリケーション側で実装した場合についての記述です。
|
|
5
|
+
次のような文章が２３８ページにありました。オートナンバリングの実現方法としてアプリケーション側で実装した場合についての記述です。
|
|
6
6
|
|
|
7
7
|
なお、オートナンバリングで作られる代理キーは市町村についてのデータを管理する「市町村」テーブルにあります。さらに、アプリケーション側の実装では、採番テーブルという一行一列の整数を保持したテーブルを用い、他のテーブルに要素が挿入されるたび、値をインクリメントしていきます。
|
|
8
8
|
|
|
9
9
|
|
|
10
10
|
|
|
11
|
-
「おそらく最大の問題は、排他制御の仕組みをきちんと作らないと機能的なバグを生み出してしまうことです。考えてみればわかることですが、二人以上の人間が同時に採番テーブルにアクセスして、同じ番号を引き当ててしまったら、「市町村」テーブルへのINSERT時に一意制約違反がおきます。また、逆に番号が飛び石になってしまうこともあります。これを防止するには、一人が採番テーブルにアクセスした時点でテーブルをロックし、他の人間は
|
|
11
|
+
「おそらく最大の問題は、排他制御の仕組みをきちんと作らないと機能的なバグを生み出してしまうことです。考えてみればわかることですが、二人以上の人間が同時に採番テーブルにアクセスして、同じ番号を引き当ててしまったら、「市町村」テーブルへのINSERT時に一意制約違反がおきます。また、逆に番号が飛び石になってしまうこともあります。これを防止するには、一人が採番テーブルにアクセスした時点でテーブルをロックし、他の人間は参照も更新もできないようにすることです。こうした排他制御を意識したプログラム作成は、複雑になりがちですし、DBMS間でトランザクション分離レベルが異なることも多いため、異なるDBMSにプログラムを移植するにも、簡単にはいきません。」
|
|
12
12
|
|
|
13
13
|
|
|
14
14
|
|