データベースのテーブル設計について

質問

データベースのテーブル設計で、数項目のみのデータをひとつのテーブルにしていますでしょうか？

すべてデータベース内で管理するという一貫性はあると思うのですが、たかだか数項目なのでどうかなとも思ってしまいます。

かといって、数項目のみのデータをプログラム内（たとえば構造体）で管理するというのも、管理が必要な要素が散らばるし、再コンパイルも必要になってきます。

このあたりどのようにすればよいのかなといつも判断に悩んでいます。

みなさんはどのように判断、設計していますでしょうか？ご意見お教えください。

回答No.1

SteveStrawb · ベストアンサー

１項目だけでも１つのテーブルにすることはあります。それが「リレーショナル」な設計である場合が往々にしてあります。項目数で判断するものではありません。

回答No.4

mitoneko

テーブルの項目の質に寄ります。というのが正直な所でしょうか。

　一応、テーブル設計の際には、第三正規化を完了した構造をスタートに、効率を考慮して重複データを持たせるかどうかを検討しますが、フィールドが２つだけの表なんてのも、よく出現したりします。（キーテーブルとかに良く出現しますね。キーコードとその表記があるだけの表です。）

　よほどの事情がない限り、別構造でデータを管理することはしません。（プロセス単位で個々に管理しなければならないとか・・・）でも滅多に発生しませんね。
　一群のデータを統一した形で管理することがＤＢＭＳの最大のメリットですから、データの一部を外部で管理したら、ＤＢＭＳの価値が半減してしまいます。管理にも手間がかかるし、データの流用はさらに大変になりますし、システムの更新をする際には必ずネックポイントになりまし・・・あまり良いことは無いと思います。

回答No.3

yutopapa

私も皆さんと同じ意見で、数項目であってもテーブルとして設計しています。
システムの環境情報、設定情報の類ですよね。

但し、D/Bの接続情報（DB名やユーザー名など）は、当然D/Bに置けませんので、別途プログラムの外側のテキストファイルで環境設定出来るようにしています。
（iniファイルとか、レジストリと同じイメージです。）

この２つのどちらを使うかケースバイケースで使い分ければ良いのではないでしょうか。

回答No.2

ymmasayan

とにかく何も考えずにテーブルにすべきです。
一部例外を作ってしまうと、後のメンテ拡張で泣く事になります。
よほどの場合は特別扱いをするかどうか思案のしどころとなります。