回答編集履歴
3
追記
answer
CHANGED
|
@@ -14,4 +14,6 @@
|
|
|
14
14
|
また、データを重複して持つのではなく、ビューを作成するという方針も考えられます。
|
|
15
15
|
他の回答にもあるようにRDBMSの外側にデータを持つ方法もあります。
|
|
16
16
|
|
|
17
|
-
何が最適なのかは「要件による」としか言えないので、様々な可能性を含めて、メリットやデメリットを勉強してみるのも良いんじゃないでしょうか。
|
|
17
|
+
何が最適なのかは「要件による」としか言えないので、様々な可能性を含めて、メリットやデメリットを勉強してみるのも良いんじゃないでしょうか。
|
|
18
|
+
|
|
19
|
+
ただし、そこまでいくとシステムアーキテクチャ設計とかそういうレベルになるので、「DB設計の勉強をしています」という前提なら「必要ない」という回答で終わりです。
|
2
追記
answer
CHANGED
|
@@ -9,4 +9,9 @@
|
|
|
9
9
|
|
|
10
10
|
明確な理由もなく「パフォーマンス的に良くないのでは？」という程度の話でなく、例えば実際にテストデータを入れてパフォーマンス計測等を行って決める（或いは過去のデータ等から計算で導く）、という手順を踏むべき話です。
|
|
11
11
|
|
|
12
|
-
なにを目的とした「勉強」かによりますが、実務を強く意識してやるのであれば、例えば応答時間やCPU、メモリ、ディスクI/Oの負荷などを計測する、というところまでやって「冗長なデータを持つべきか」を判断する資料を作成するところまで勉強したら良いのではないでしょうか。
|
|
12
|
+
なにを目的とした「勉強」かによりますが、実務を強く意識してやるのであれば、例えば応答時間やCPU、メモリ、ディスクI/Oの負荷などを計測する、というところまでやって「冗長なデータを持つべきか」を判断する資料を作成するところまで勉強したら良いのではないでしょうか。
|
|
13
|
+
|
|
14
|
+
また、データを重複して持つのではなく、ビューを作成するという方針も考えられます。
|
|
15
|
+
他の回答にもあるようにRDBMSの外側にデータを持つ方法もあります。
|
|
16
|
+
|
|
17
|
+
何が最適なのかは「要件による」としか言えないので、様々な可能性を含めて、メリットやデメリットを勉強してみるのも良いんじゃないでしょうか。
|
1
修正
answer
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
> それとも冗長になるため予約テーブルだけにするべきでしょうか？
|
|
2
2
|
|
|
3
|
-
勉強
|
|
3
|
+
単純なスキーマ設計の勉強であれば、原理原則に則って、導出可能なデータは持つべきではありません。
|
|
4
4
|
|
|
5
5
|
> しかし、毎回空き状況確認するために予約テーブルから計算するのはパフォーマンス的に良くないのでは？と思いました。
|
|
6
6
|
|