1列のテーブルは良いデザインですか？[閉まっている]

列が1つだけのテーブルがあってもよろしいですか？技術的に違法ではないことは知っていますが、デザインが悪いと考えられますか？

編集：

以下にいくつかの例を示します。

• 50の有効な米国の州コードを持つテーブルがありますが、詳細な州名を格納する必要はありません。
• メールのブラックリスト。

キーフィールドの追加について誰かが言及しました。私の見たところ、この単一の列が主キーになります。

はい、テーブルを最も効率的な方法で設計することは確かに良い設計です。「不良RDBMS設計」は通常、非効率性が中心です。

ただし、シングルカラム設計のほとんどの場合、追加のカラムを使用するとメリットがあることがわかりました。たとえば、州のコードでは、通常、2番目の列に州のフルネームを綴ることができます。または、ブラックリストにメモを関連付けることができます。しかし、デザインが実際にその情報を必要としない場合は、単一の列があってもまったく問題ありません。

これに関してはrelational algebra、「このことが存在する」という意味の単項関係になります」。

はい、そのような関係を定義するテーブルがあれば問題ありません。たとえば、ドメインを定義します。

もちろん、このようなテーブルの値は自然な主キーでなければなりません。

prime numbers最初に頭に浮かぶのは、ルックアップテーブルです。

過去に使ったことがあります。私のクライアントの1人は、この大きなリストにある電話番号で登録しようとするユーザーを自動ブロックしたかったので、1つの大きなブラックリストにすぎませんでした。

正当なニーズがある場合、問題は発生しません。たぶん、何らかの理由で表示する可能性のあるリストが必要で、動的に変更できるようにしたいが、別のテーブルにリンクする必要がない場合があります。

私が時々見つけた1つのケースは次のようなものです：

テーブルcountries_idには、国ごとに数値IDを持つ列が1つだけ含まれています。

テーブルcountries_descriptionには、国IDの列、言語IDの列、ローカライズされた国名の列が含まれています。

テーブルcompany_factoriesには、Wichにある国を含む、会社の各工場の情報が含まれています。

したがって、テーブル内のデータの一貫性と言語に依存しないデータを維持するために、データベースはこのスキーマを1列のみのテーブルで使用し、言語に依存せずに外部キーを許可します。

この場合、1つの列テーブルの存在が正当化されると思います。

へのコメントに応じて編集： Quassnoi

_{（ソース：ggpht.com）}

このスキーマでは、company_factoriesテーブルに外部キーを定義できますが、テーブルにLanguage列を含める必要はありませんが、countries_idテーブルがない場合は、外部キーを定義するためにテーブルにLanguage列を含める必要があります。

単一列のテーブルが理にかなっているまれなケースがあります。有効な言語コードのリストが外部キーとして使用される単一列のテーブルであるデータベースを1つ作成しました。コード自体がキーだったので、別のキーを持つことに意味はありませんでした。また、一部のコンテキストでは言語コードの説明が言語によって異なるため、修正された説明はありませんでした。

一般に、追加の属性を持たない信頼できる値のリストが必要な場合は、1列のテーブルに適しています。

私は常に単一列のテーブルを使用しています-もちろん、アプリのデザインが既にデータベースを使用しているかどうかにもよりますが。データベース接続を確立するオーバーヘッドの設計に耐えたら、可能な場合はすべての変更可能なデータをテーブルに入れます。

単一列テーブルOTMHの2つの使用法を考えることができます。

1）データ項目が存在します。ドロップダウンリストでよく使用されます。単純な正当性テストにも使用されます。

例えば。2文字の米国の州の略称。発送先の郵便番号。スクラブルで合法的な言葉; 等

2）スパースバイナリ属性。つまり、大規模なテーブルでは、ごく少数のレコードにのみ当てはまるバイナリ属性。新しいブール列を追加する代わりに、属性がtrueであるレコードのキーを含む別のテーブルを作成する場合があります。

例えば。末期疾患のある従業員; 年間360日の銀行（ほとんどが365を使用）。等

-アル。

一意の値が含まれていれば問題ありません。

ほとんどの場合、これはあなたが説明した状態テーブルなどのルックアップタイプのテーブルで見られます。ただし、これを行う場合は、一意性を強制するために列を主キーとして設定してください。この値を一意として設定できない場合は、1つの列を使用しないでください。

私は一般的にそう言うでしょう。列が1つだけ必要な理由がわかりません。これにはいくつかの例外があり、効果的に使用されています。それはあなたが達成しようとしていることに依存します。

データベースのスキーマを考えると、これらは本当に良い設計ではありませんが、実際にはユーティリティテーブルとしてのみ使用する必要があります。

私は過去に効果的に使用された数値テーブルを見てきました。

データベースの目的は、情報を相互に関連付けることです。関連するデータがない場合、どうすればよいですか？

たぶん、これはある種のコンパイルテーブル（つまり、FirstName + LastName + Birthdate）ですが、なぜそうしたいのかはまだわかりません。

編集：私はある種の簡単なリストのためにこの種のテーブルを使用することを見ることができました。それを何のために使っているのですか？

はい、あなたが言ったようにフィールドが主キーである限り。その理由は、重複したデータを挿入した場合、それらの行は読み取り専用になるためです。重複している行の1つを削除しようとした場合。サーバーは削除する行を認識しないため、機能しません。

私が思いつくことができる唯一のユースケースは、おそらく単語ゲームの単語表です。文字列が単語であることを確認するためだけにテーブルにアクセスします。単語=？の単語から単語を選択します。ただし、単語のリストを保持するためのデータ構造は、リレーショナルデータベースよりもはるかに優れています。

それ以外の場合、データベースのデータは通常、データベースに配置され、データのさまざまな属性間の関係を利用します。データにその値を超える属性がない場合、これらの関係はどのようにして開発されますか？

したがって、違法ではありませんが、一般的には、たった1列のテーブルを作成するべきではありません。

私のすべてのテーブルには、少なくとも4つの技術フィールド、シリアル主キー、作成と変更のタイムスタンプ、およびブール値のソフト削除があります。どのブラックリストでも、誰がエントリを追加したかを知ることもできます。したがって、私にとっては答えは「いいえ」です。列を1つだけ持つテーブルは、何かをプロトタイプ化する場合を除いて意味がありません。

はい、それで問題ありません。しかし、IDフィールドはそれを正しく傷つけることができませんでしたか？