database - テーブルに「多すぎる」フィールドはいくつありますか?

Question

それぞれ 30 を超えるフィールドを持つ複数のテーブルを持つ新しいアプリ用のデータベースを計画している同僚がいます。これは過剰ですか？多分私は理解するのに十分なほど積極的ではありません。

編集：また、多くのフィールドはオプションタイプのものです（リクエストフォームのように、ウィジェットを黄色または緑色にしたい場合、列挙型の「色」のフィールドがあります）。これらは時間の経過とともに追加または削除される可能性が非常に高いです。私は実際にデータベースの設計を行ったことがなく、自分でそれを避けようとしているので、完全に愚かであるかもしれませんが、これを行うためのより良い方法は確かにあります??

score 13 · Accepted Answer

テーブルが正規化を必要とする最も明白な兆候は、整数で終わるフィールドです。ただし、いつものようにルールには例外があります。

score 12 · Accepted Answer

データベーステーブルには、合法的に 30 以上のフィールドを含めることができます。確認する必要があるのは、データの正規化と、その正規化に意味があるかどうかです。通常、将来的にも変更されます。ただし、それを最小限に抑えたいと考えています。

たとえば、住所を含むテーブルがある場合、そのテーブルに都市、州、および郵便番号のフィールドを含めますか? または、それらの値の別のテーブル内のレコードを「指す」フィールドを 1 つだけ含めますか? 別のテーブルには、一意の都市、州、郵便番号の組み合わせが含まれます。データを 2 つのテーブルに分割すると、保存されるデータの量が減少しますが (ほとんどの場合、絶対的ではありません)、データベースに対してクエリを実行する際の複雑さが少し増します。ここでは、1 つではなく 2 つのテーブルを処理する必要があります。しかし、明るい面としては、はるかにクリーンで、はるかに小さい (可能性が高い) ということです。

本当の答えは、適切な状況では、city-state-zip データをアドレステーブルに残しても問題ないということです。または、それを「正規化」したい場合があります。どちらも大丈夫です。

優秀なデータベース管理者を見つけて、短期間雇って計画を見直します (予算内であれば)。長期的には報われるでしょう。

score 8 · Accepted Answer

30 個のフィールドは多すぎません。データが適切に正規化されていることを確認する必要があるだけです (Web 上にはガイドがたくさんあります)。

多くの列が時間の経過とともに追加または削除される可能性のあるオプションタイプのフィールドになることを指定する編集に基づいて、次のことをお勧めします。

BaseTable:
    Id
    NonOptionFields
OptionTable:
    Id
    OptionName
    OptionValue

次に、すべてのオプションをベースレコードに関連付けることができます。これは、目的を達成するために常に正規化された方法でテーブルに列を追加および削除する必要がないことを意味します。

score 7 · Accepted Answer

もちろん、標準的な答えは、場合によるというものです。これほど多くのフィールドを持つテーブルは、状況によっては実際に非常に意味のあるものになる可能性があります。

そこに保存するデータについて考えてみましょう。これらのフィールドの多くが NULL になる可能性はありますか? これらのフィールドが変更される可能性はどのくらいですか (例: さらに追加される)?

特定のフィールドのみが特定のオブジェクトに適用される場合は、それらのフィールドを別のテーブルに配置することを検討してください。または、基本的な共通フィールドのみを 1 つのテーブルに格納し、追加情報を別のテーブルに格納します (フィールドごとに 1 行)。私が別の質問に対して提案したように（これはあなたに役立つかもしれません）：

refs (id、タイトル、refType)
-- 参考文献のタイトルと参考文献の種類

fieldDef (id、フィールド名、refType、dataType)
-- フィールドの名前、適用される参照型、および
-- これらのフィールドに格納されるデータの種類 (ISDN 番号、日付など)

フィールド (refId、fieldId、値)
-- 実際に参照にデータを追加する場所。

これは反対票を投じられたことに注意してください。おそらく正当な理由があります。これはオプションであり、必ずしも最適なオプションではありませんが、それでも実行可能な方法です。ただし、リンクした質問で最も投票された回答が最善の解決策である可能性があります。

編集：ユーザーごとの設定（ウィジェットの色など）などを保持するとおっしゃっているので、実際には上記の方法（3つのテーブルを使用）をお勧めします。ほとんどの人はデフォルトのままにしておく可能性が高いので、役に立たない情報の山が保存されます。他の読者がこの方法の欠点を指摘しているので、他の質問で私の答えを読んでください。

score 4 · Accepted Answer

恣意的な制限はありません。仕事を終わらせるのに十分であることは経験則です

より良いデータベース設計がある場合は、それを提案してください

より詳細なフィードバックが必要な場合は、スキーマを投稿してください

score 4 · Accepted Answer

「多すぎる」という用語は相対的なものです...フィールドの数を減らすためだけにテーブルを分割しないでください。特に、すべてのクエリでそれらを結合し直す必要がある場合は、基本的に一対一の関係。フィールドを個別の論理オブジェクトに分解できる場合、それは理にかなっています。たとえば、住所フィールドを顧客テーブルに格納する代わりに、別の住所テーブルに移動できます。これは大まかな例ですが、私の要点を示しています。

score 3 · Accepted Answer

通常、フィールドの数は問題になりませんが、データベースが正しく正規化されていることを確認する必要があります。第 3 正規形は良い出発点です。

score 2 · Accepted Answer

「このテーブルにはフィールドが多すぎますか?」と尋ねなければならない場合は、それからおそらくあります。

score 1 · Accepted Answer

データベース理論では、フィールド数に制限はありません。テーブルは主キーに限定される可能性があり (この主キーが 2 つのフィールドで構成されている場合でも)、Apocalisp の答えはあまり明確ではありません。反対に、通常の形式の規則が守られている限り、何千ものフィールドからテーブルを作成できます。

フィールドのグループがテーブルで明らかに十分に使用されていない場合、このフィールドのグループを別のテーブルに分割し、メインテーブルと「サブ」テーブルの間に 0-1 の関係を持たせるのが賢明です。

セキュリティ上の理由から、機密情報を別のテーブルに分割し、メインとサブ。その後、「サブ」テーブルへのユーザーアクセスを簡単に制限することができました。このような構成は、ビューを介して簡単に管理できるようになりました。

score 1 · Accepted Answer

デフォルトでの正規化へのゲリラのガイド:

テーブルには、主キーと、最大で 1 つの他の列が必要です。
規則番号 1 は、必要な回数だけ破ってください。

score 0 · Accepted Answer

テルテールサインはまさにあなたが言ったことです。彼は、理論的には別のテーブルに分割する必要があるフィールドを持っています。もう 1 つの利点は、多くのオプションフィールドが存在することです。

DB「エキスパート」には、データベース設計のコースが適していると思います。そして、あなたもそれをブラッシュアップすることをお勧めします...それはあなたのキャリアの成長に役立つだけです:)

database - テーブルに「多すぎる」フィールドはいくつありますか?

12 に答える 12

Related

Reference