回答編集履歴
2
edit
answer
CHANGED
@@ -10,7 +10,7 @@
|
|
10
10
|
「性能」や「運用」「拡張性」含めた、非機能要件にあたります。
|
11
11
|
|
12
12
|
[帳簿書類等の保存期間](https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5930.htm)(電子帳簿も含む)が国としても定義されていますが、データは半永久に保持し続けるわけではなく、サーバ容量も有限なので、「どれくらいの期間保持するデータなのか」を定義します。
|
13
|
-
「その期間でどれくらいのデータ量になるか」を先に概算しておく必要がありますし、その概算を元にサーバ容
|
13
|
+
「その期間でどれくらいのデータ量になるか」を先に概算しておく必要がありますし、その概算を元にサーバ容量が決まります。
|
14
14
|
|
15
15
|
そして、「期間が過ぎたデータをどうするのか」「バックアップは」なども決めます。
|
16
16
|
単純に削除するのか、DB分割して別サーバに保持するのか等々、様々な選択肢の中から決めます。
|
1
edit
answer
CHANGED
@@ -26,4 +26,12 @@
|
|
26
26
|
**必要だからそのテーブルを作った**わけですから、
|
27
27
|
数を気にして正規化が行われない方が問題です。
|
28
28
|
|
29
|
-
定期的な見直しは必要ですけどね。
|
29
|
+
定期的な見直しは必要ですけどね。
|
30
|
+
|
31
|
+
> 一つは、該当のテーブルを見つけるまでの処理。
|
32
|
+
|
33
|
+
SELECT時にテーブル1つしか対象としないなら「見つけるまで」なんて存在しないのでは。
|
34
|
+
テーブルが多いから単純SELECTが遅くなるなんてことはないはずです。
|
35
|
+
上から1つ1つ見に行くわけではなく、いきなりそのテーブルを見るわけですから。
|
36
|
+
データベースのメリットはそこです。
|
37
|
+
データ量が多くてもいきなりそのデータを取り出せるようになっています(もちろんINDEXは適切に貼られているべき)
|