テーブル設計において

質問

データベース（RDB）のテーブルを設計する際に、
データの連結の関係を考えた際に、連結の関係は簡単にしておいたほうがいいのかそれとも実登録データの量をとにかく少なくするように
したほうがいいのかで悩んでいます。
今現在やっているのがデータベースのデータ量を少なくするためといって、非常にややこしくなっています。
正直今現在DBに登録するデータというのがテキストおよび数値データのみで、画像や動画といったバカデカイコンテンツデータは登録するようになっていないシステムにおいて、HDDやストレージがパンクするといったことがまずありえないぐらいの容量はあるんじゃないかなとおもっています。これってどうなんだろうと思って質問しています。皆さんはどう考えていますか？

回答No.6

CHRONOS_0

>正規化外しによる効果が10倍である！
この認識は大きく違いますよ
処理を重ねると、処理量はデータ量の掛け算で増えていきます
乱暴な計算をすれば、1万レコードの処理を重ねると10000*10000になります
これが正規化外しで10000+10000+何がし、ぐらいに抑えられます

実際大きなシステムではどこかで正規化外しを取り入れているものがほとんどじゃないでしょうか

>スピードを優先しているか、拡張性を優先しているか
どちらも優先します。
その辺の匙加減が設計者の腕の見せ所ですね

回答No.5

kalkichi

ANo.3,4の方がおっしゃる通りでしょうね。
高速化の為の冗長化であって、目的のクエリが書けない、メンドクサイから冗長化というのはあり得ません。処理速度が上がった今だからこそ正規化です。正しく正規化されていれば後々の変更にも柔軟に対応できます。

回答No.4

CHRONOS_0

>メリットとなっていた点は今でもメリットのまま残っているのか？
>デメリットは今でも意識しなければならないほどのデメリットなのか？
「HD容量が巨大になっても正規化しないといけないか」という意味かな
>実登録データの量をとにかく少なくするように
正規化はサイズを小さくするためにやるのではないですよ
データの整合性を確保するために行うものです

ただし、正規化をとことん進めると
>データ量を少なくするためといって、非常にややこしくなっています。
こういうデメリットではなく処理に時間がかかるというデメリットが生じます
>CPUは10倍近く速くなってますよね・・・
能力が上がった分、処理する量も増えてきていますから
今でも処理速度を速める工夫は必要です(たぶん今後も)

[正規化外し]は処理速度を速めるために行われるものです
正規化を外せば、整合性から外れたデータの格納が可能になります

ですから
>今でもメリットのまま残ってい
ますし
>デメリットは今でも意識しなければな
りません

補足

再度のご回答ありがとうございます。
ですがまだ認識にずれがあります。

>「HD容量が巨大になっても正規化しないといけないか」という意味かな
ここが違います。
あえていうなら、むしろ「HD容量が巨大になっても正規化外しをしないといけないか」です。
私は正規化しなくていい、ましてや正規化がめんどくさいと考えているわけではありません。
（というかこの質問でそのように感じられるなら私の表現力不足です。orz）
個人的な考えでしかありませんが、基本的にシステムの設計する際に、考える必要があることとして、拡張性はかなり大きいと考えています。
機能追加や機能変更、運用の変更への対応などが起きないシステムって存在しないと思います。
だとした場合、十分な正規化は行い、その上でシンプルな構成であることのほうが大事ではないでしょうか？処理するデータについても確かに能力が上がった分処理する量が増えるとしても、それを意識する必要があるほど増えているのか？という疑問があります。
正直、正規化外しによる効果が10倍である！
としても、30年前は、処理時間が30分かかっていたものが3分になっていたとした場合、ハードの処理速度があがり、実際の処理時間が0.001秒を5分に1回ぐらいしか使わないとしたら、処理時間0.01秒にするために柔軟性すてていいのか？という気がします。
逆にどんなにシンプルにしても遅くて運用になりませんじゃ意味は皆無なわけですし。
スピードを優先しているか、拡張性を優先しているか
というのをDBのテーブル設計レベルでどう意識しているのかなというとこが聞きたかったわけです。
なので、
> 能力が上がった分、処理する量も増えてきていますから
> 今でも処理速度を速める工夫は必要です(たぶん今後も)
というのはごもっともです。
ということで、やっと聞きたいことがまとまった気がしますが、個人的にはどっちを優先されていますか？

回答No.3

CHRONOS_0

>非常にややこしくなっています。
どの程度のものをややこしいと感じておられるのかは
質問者のスキルによりますから、なんともいえないところですが

正規化は面倒だからいい加減でいいという考えではいい設計は出来ません
確かに「正規化外し」というものは行われますが
あくまでも[意図的に]外す「外し」であって[外れ]や[忘れ]、[無視]ではありません

正規化外しは正規化についてよく理解している熟練者が
外すことによるメリットとデメリットをよく理解し
メリットのほうが大きいと考えて意図的に外すものです
その際、デメリットに対する対応策を組み込むことも忘れてはなりません

初心の間は正規化を守るという方がいいでしょうね

お礼

ご回答ありがとうございます。

ですが、申し訳ありません。
正規化した後、もしくはする前の段階での考えについてお聞きしたいわけです。
当然正規化考えないならRDB使うのってあまり意味がないと考えます。
（今回正規化という言葉を(ry ）
私が聞きたかったのはその意図的な外しにおいて
メリットとなっていた点は今でもメリットのまま残っているのか？
デメリットは今でも意識しなければならないほどのデメリットなのか？
とかをお聞きしたいわけです。

と説明と質問がわかりにくいのを棚に上げてえらそうなことをいって申し訳ありませんorz
もうちょっとわかりやすい質問できるように気をつけます。

回答No.2

ymmasayan

ＲＤＢの設計ではまず「正規化」が大切です。
第一正規化から第五正規化まで有りますが通常は第三正規化で設計します。

お礼

ご回答ありがとうございます。
もちろん正規化は意識して設計するわけですが、
でもそれを意識する前の「どのようなデータが必要か？」
を決める際の話かなと考えてます。
10年前に比べてもクライアントでもHDDは10G（もあったかな？）が500G
とか普通にある状態ですし、CPUは10倍近く速くなってますよね・・・

えー正規化という言葉を今回初めてしったので違うだろとお思いでしたらご意見ください（＾＾；

回答No.1

yasu2209

私は素人ですが、かつての経験を一つお話します。
私もデータベースの設計をするとき、データ量の圧縮のために非常な複雑な工夫をし、ソフトを完成させました。昔はストレージ容量も少なく、ある程度はやむを得なかったのですが・・。ところが後になって、ソフトの変更や修正が必要になったとき、あまりにも複雑、かつタイトに設計してしまったため、変更の自由度がなく、非常に苦労した経験があります。
以後、余裕がある限りは構造的にすっきりしたプログラミングをするよう心がけています。
基本的には「誰が見ても理解できる構造」です。
ご質問の主旨と違うかもしれませんが参考に。

お礼

ご回答ありがとうございます。
私が聞きたかったのはそのところです。
PGのロジックにあわせてスピードを最優先にするためにはこういう構造じゃないとだめだ！
ってことにしてしまうと後で業務内容変わってしまうと修正に時間がかかってしまったり・・・データのコンバートが必要になったり
とかよくあるんです。
現在かなり処理速度や容量も発展しているわけですが
今みなさんはどう意識してるかなと思ってたわけです。

ありがとうございました。