Q&A
以下少々抽象的な内容になっていまいますが、アドバイス頂ける範囲でお願いいたします。
お題としては、色々な内容を記入して行政に提出する書類をWebで作成する
システムのテーブル設計についてです。（以後、書類テーブルと呼びます。）
書類データの目的は、エビデンスを残すことが第一で、
各項目において、アンケートのように集計・分析される予定はなく、
基本的にはプレビューや出力されるだけです。
出力後においては削除もさせない仕様です。
実物書類にはいくつか繰り返し項目がありますが
フォーマットが決まっているため、最大繰返回数は決まっております。
(少なくて3回、多くて8回)
この時、素直に書類テーブルについて項目を並べていくと
カラム数が80近くなります。
第一正規系にすると、いくつもテーブルが増えることに対して
見返りがいまいち合わないような気がするという感覚と
カラム数が多く分割（第一正規化）したほうがいいのかというジレンマがあり、
どちらに寄せていいのかというところについて、
皆様のご意見を頂きたいです。
（現状、最大8回繰り返されるセクションのみ別テーブルに正規化しましたが...）
以上のところまでで、まだまだ前提となる情報など足らないかもしれませんが
お願いします。
回答1件
0
ベストアンサー
書類データの目的は、エビデンスを残すことが第一で、
各項目において、アンケートのように集計・分析される予定はなく、
基本的にはプレビューされるだけです。
書類作成から出力後においては削除もしない仕様です。
作成途中のテーブルは別に用意して、過去の履歴として参照するだけのテーブルなら、
配列型の項目に格納するのもありかと個人的には思います。
自身の経験として、照会のみの履歴データが大量にあり、正規化するとキーの項目サイズだけで馬鹿にならず、配列にした事があります。
幸い、postgresは配列を扱う関数が充実していることもあり、照会時にはSQLで正規化されたレイアウトに展開するようにしていました。
ただ、配列項目に対してginインデックスを設定しても、期待した性能がでず、SQL内で正規化したものを検索するようした方が早いなどという事はありましたが。
尚、上記はあくまで正規化後の行方向を配列に纏めたということで、列方向を配列に纏めるということは行いません。
追記
例えば、書類(書類ID,１章,２章,・・・・,８章)、があったとして、
書類(書類ID,章番号,文)、とするのは正規化から外れているとは思いません。
ここから正規化を緩めて、**書類(書類ID,文[])とします。
※繰り返しが固定なら、配列の要素は決め打ちで保持('{Null,Null,・・・,Null}')の方が扱いやすいと思いますが、拡張まで考えると書類(書類ID,章番号[],文[])**のようにして、**章番号[]を文[]**の見出しとして扱うのが良いかもしれません。
見直ししてみると、ちょっと構成が違うのかなと思いましたので、再考。
書類(書類ID,[{A,B,C・・・},{A,B,C・・・},・・・{A,B,C・・・}])※{A,B,C・・・}が８回繰り返し
並べて８０個程の項目というのが上記のような構成だとすると、正規化では
**書類(書類ID,連番,A,B,C・・・)**という構造になるかと思いますので、特段問題は無さそうに感じます。
追記２
コメントにある内容なら、章ごとにテーブルを分ける必要は無い気がします。
章ごとに子テーブル
子テーブルと言われている構造を推測すると、
第X章(書類ID, 節番号, 項目A,項目B,項目C) ※節番号が１～８
でしょうか
以下のように章番号ごとの構造にすれば、章ごとにテーブルにする必要はありません。
書類(書類ID, 書類名, ・・・[書類固有の属性])
本文(本文ID, 書類ID, 章番号, 節番号, 見出し, 項目A,項目B,項目C)
※書類IDと本文IDがサロゲートキー
上記のような構成の方が、例えば目次を取り出す（本文から見出しを列挙）なども容易ですし。
正規化の段階では、繰り返しが大きいか小さいかではなく、繰り返しする項目であるかどうかが重要です。
尚、正規化したものについては、どのようなOUTPUTで利用するのかも考慮は必要です。
正しく正規化されているものではあるけれど、抽出するのが手間になるということはありますので。
投稿2018/03/30 07:03
編集2018/04/02 04:23
総合スコア25195
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/04/02 04:20 編集
2018/04/27 00:15