『ボヘミアン・ラプソディ』はなぜ人々を魅了したのか >>

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

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

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

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

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

このQ&Aに関連する最新のQ&A

A 回答 (4件)

1項目だけでも1つのテーブルにすることはあります。

それが「リレーショナル」な設計である場合が往々にしてあります。項目数で判断するものではありません。
    • good
    • 0

 テーブルの項目の質に寄ります。

というのが正直な所でしょうか。

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

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

私も皆さんと同じ意見で、数項目であってもテーブルとして設計しています。


システムの環境情報、設定情報の類ですよね。

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

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

とにかく何も考えずにテーブルにすべきです。


一部例外を作ってしまうと、後のメンテ拡張で泣く事になります。
よほどの場合は特別扱いをするかどうか思案のしどころとなります。
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す


人気Q&Aランキング