回答編集履歴

5

追記

2018/04/02 04:23

投稿

sazi
sazi

スコア25199

test CHANGED
@@ -51,3 +51,41 @@
51
51
  並べて80個程の項目というのが上記のような構成だとすると、正規化では
52
52
 
53
53
  **書類(書類ID,連番,A,B,C・・・)**という構造になるかと思いますので、特段問題は無さそうに感じます。
54
+
55
+ 追記2
56
+
57
+ ---
58
+
59
+ コメントにある内容なら、章ごとにテーブルを分ける必要は無い気がします。
60
+
61
+ > 章ごとに子テーブル
62
+
63
+
64
+
65
+ 子テーブルと言われている構造を推測すると、
66
+
67
+ **第X章(書類ID, 節番号, 項目A,項目B,項目C)** ※節番号が1~8
68
+
69
+ でしょうか
70
+
71
+
72
+
73
+ 以下のように章番号ごとの構造にすれば、章ごとにテーブルにする必要はありません。
74
+
75
+ **書類(書類ID, 書類名, ・・・[書類固有の属性])**
76
+
77
+ **本文(本文ID, 書類ID, 章番号, 節番号, 見出し, 項目A,項目B,項目C)**
78
+
79
+ ※書類IDと本文IDがサロゲートキー
80
+
81
+ 上記のような構成の方が、例えば目次を取り出す(本文から見出しを列挙)なども容易ですし。
82
+
83
+
84
+
85
+ 正規化の段階では、繰り返しが大きいか小さいかではなく、繰り返しする項目であるかどうかが重要です。
86
+
87
+
88
+
89
+ 尚、正規化したものについては、どのようなOUTPUTで利用するのかも考慮は必要です。
90
+
91
+ 正しく正規化されているものではあるけれど、抽出するのが手間になるということはありますので。

4

追記

2018/04/02 04:23

投稿

sazi
sazi

スコア25199

test CHANGED
@@ -39,3 +39,15 @@
39
39
  ここから正規化を緩めて、**書類(書類ID,文[])**とします。
40
40
 
41
41
  ※繰り返しが固定なら、配列の要素は決め打ちで保持('{Null,Null,・・・,Null}')の方が扱いやすいと思いますが、拡張まで考えると**書類(書類ID,章番号[],文[])**のようにして、**章番号[]**を**文[]**の見出しとして扱うのが良いかもしれません。
42
+
43
+
44
+
45
+ 見直ししてみると、ちょっと構成が違うのかなと思いましたので、再考。
46
+
47
+
48
+
49
+ **書類(書類ID,[{A,B,C・・・},{A,B,C・・・},・・・{A,B,C・・・}])**※{A,B,C・・・}が8回繰り返し
50
+
51
+ 並べて80個程の項目というのが上記のような構成だとすると、正規化では
52
+
53
+ **書類(書類ID,連番,A,B,C・・・)**という構造になるかと思いますので、特段問題は無さそうに感じます。

3

追記

2018/03/30 09:51

投稿

sazi
sazi

スコア25199

test CHANGED
@@ -27,3 +27,15 @@
27
27
 
28
28
 
29
29
  尚、上記はあくまで正規化後の行方向を配列に纏めたということで、列方向を配列に纏めるということは行いません。
30
+
31
+ 追記
32
+
33
+ --
34
+
35
+ 例えば、**書類(書類ID,1章,2章,・・・・,8章)**、があったとして、
36
+
37
+ **書類(書類ID,章番号,文)**、とするのは正規化から外れているとは思いません。
38
+
39
+ ここから正規化を緩めて、**書類(書類ID,文[])**とします。
40
+
41
+ ※繰り返しが固定なら、配列の要素は決め打ちで保持('{Null,Null,・・・,Null}')の方が扱いやすいと思いますが、拡張まで考えると**書類(書類ID,章番号[],文[])**のようにして、**章番号[]**を**文[]**の見出しとして扱うのが良いかもしれません。

2

修正

2018/03/30 08:10

投稿

sazi
sazi

スコア25199

test CHANGED
@@ -26,4 +26,4 @@
26
26
 
27
27
 
28
28
 
29
- ただ、上記はあくまで行方向を配列に纏めたということで、列方向を配列に纏めるということは行ったことは無です
29
+ 、上記はあくまで正規化後の行方向を配列に纏めたということで、列方向を配列に纏めるということは行いません

1

追記

2018/03/30 07:54

投稿

sazi
sazi

スコア25199

test CHANGED
@@ -23,3 +23,7 @@
23
23
 
24
24
 
25
25
  ただ、配列項目に対してginインデックスを設定しても、期待した性能がでず、SQL内で正規化したものを検索するようした方が早いなどという事はありましたが。
26
+
27
+
28
+
29
+ ただ、上記はあくまで行方向を配列に纏めたということで、列方向を配列に纏めるということは行ったことは無いです。