通常、データの冗長性を回避するためにデータベースを正規化します。名前でいっぱいのテーブルを見ると、冗長性が十分にあることが簡単にわかります。あなたの目標が地球上のすべての人の名前のカタログを作成することである場合（幸運）、名前を正規化することがいかに有益であるかがわかります。しかし、平均的なビジネスデータベースのコンテキストでは、それはやり過ぎですか？
（もちろん、私はあなたが極端に何かを取ることができることを知っています...あなたが音節に正規化した場合...または隣接する文字のペアさえも。私はそこまで行くことの利点を見ることができません）
アップデート：
これを正当化できる理由の1つは、ランダムな名前ジェネレーターです。頭のてっぺんから思いつくのはそれだけです。
はい、それはやり過ぎです。
一度に名前をからBillに変更することはありません。Joe
通常、データベースの正規化とは、フィールドの内容ではなくフィールドの正規化を指します。つまり、データベースには名フィールドが 1 つしかないことを正規化します。それは一般的に価値があります。ただし、データ コンテンツはその人に固有であるため、正規化しないでください。リストから選択するのではなく、1 か所でリストを変更してすべての人に影響を与えるわけでもありません。これはバグであり、機能ではありません。
名前をどのように正規化しますか? すべての名前が同じ構造を持つわけではありません。すべての国や文化が同じ名前の規則を使用しているわけではありません。ファースト ネームは必ずしもファースト ネームだけではありません。人々はさまざまな数の名前を持っています。一部の国では、姓と名の単純な組み合わせがありません。私の名前がたまたまあなたの姓だった場合、データベースで同じと見なす必要がありますか? そうでない場合は、姓が国によって意味が異なる可能性があるという問題に直面します。私が知っているほとんどの国では、姓です。あなたの姓は、両親の少なくとも 1 つの姓と同じです。アイスランドでは、父親の名前の後に「息子」または「娘」が続きます。同じ苗字でも、アイスランドとアメリカで出会うかどうかによって、意味がまったく異なります。
一部の文化では、結婚時に女性が夫の姓を名乗るのが一般的です。他の文化では、それは完全にオプションであるか、逆に機能することさえあります。
これをどのように正規化できますか？どのような情報が得られますか? データベースで、名前の最後の単語が「Smith」である人を見つけた場合、それは何を示しているでしょうか? 姓ではないかもしれません。姓の一部にすぎない可能性があります。ある言語では名誉かもしれませんが、彼らの文化によれば、それは名前の一部と見なされるべきです.
データが共通の構造に従っている場合にのみ、データを正規化できます。
小さい名前に基づいてクエリを実行する必要がある場合は、名前を正規化する必要があることがわかりました。たとえば、"Betty" を検索すると、"Betty"、"Beth"、および "Elizabeth" の結果が返される必要がある場合があります。
はい、間違いなくやり過ぎです。友達の間の数十バイトは何ですか？
国勢調査局で働いているなら、それは理にかなっているかもしれません。それ以外の場合は、他のすべての回答を参照してください:)
はい、95％以上のケースで行き過ぎです。
一般的にはい。そのレベルに正規化することははるかに進んでいるでしょう。クエリ（姓による検索が一般的な電話帳など）によっては、価値がある場合があります。まれだと思います。
はい。メリットが問題やクエリの複雑さを上回っている例は考えられません。
いいえ、ただし、顧客の正規レコードに正規化することもできます (データベースで「Bloggs & Co.」の 5 つの異なるエントリを取得しないようにするため)。これは、MIS プロジェクトでしばしば発生するデータ クレンジングの問題です。
多くの場合、データベースで第 4 形式の正規化を行うことはありません。したがって、第 7 形式の正規化はかなりやり過ぎです。これが少しでももっともらしいアイデアでさえあるかもしれない唯一の場所は、ある種の大規模なデータウェアハウスです。
分割されないことに伴う削除の異常を回避する必要がある場合は、正規化する必要があります。つまり、質問に答える必要がある場合、私のデータベースに「Joejimbobjake」という名前の人が含まれている場合は、異常を回避する必要があります。ソフト削除は、（たとえば）包括的な名テーブルを作成するよりもはるかに優れた方法ですが、私の主張は理解できます。
通常、名前を正規化する必要はありません。これは主に、常に呼び出される結合にパフォーマンス ヒットが追加され、何のメリットももたらさないためです。
類似した名前が非常に多く、ストレージに問題がある場合は、その価値があるかもしれませんが、考慮する必要があるパフォーマンス ヒットがあります。
私はそれが絶対にやり過ぎだと言います。ほとんどのアプリケーションでは、人々の名前を頻繁に表示するため、それに関連するすべてのクエリは非常に複雑で読みにくくなります。
はい、そうです。正規化のすべてのルールを適用するだけで、行き過ぎて過剰に正規化されたデータベースになってしまう可能性があることは、一般的に認識されています。たとえば、すべての文字のすべてのインスタンスを文字列挙テーブルへの参照に正規化することが可能です。それがばかげていることは簡単にわかります。
正規化は、問題のドメインに適したレベルで実行する必要があります。オーバーノーマライゼーションは、アンダーノーマライゼーションと同じくらい問題です (ただし、もちろん理由は異なります)。
他の人が述べたすべてのポイントに加えて、たとえば、データ入力操作を実装していて、新しい連絡先を挿入する場合、名と姓のテーブルを検索して正しいものを見つける必要があることを考慮してください。 Id を取得し、それらの値を使用します。しかし、名前が FN テーブルや LN テーブルにない場合、これはさらに複雑になり、新しい姓名を挿入して新しい ID を使用する必要があります。
名前の包括的なリストがあると思われる場合は、もう一度考えてみてください。私は 20 万を超える固有の名前のリストを扱っており、それが米国の人口の 99.9% を表していると思います。しかし、その 0.1% = 多くの人。そして、外国人の名前とスペルミスを忘れないでください...
既婚・旧姓を紐付けできると便利な場合もあるかもしれません。
最近、ある人が離婚したため、何千通ものメールの名前を変更する必要がありました。その理由は、誰かが離婚して、彼女の名前がmarried_name@company.comになっているメールが不要になったからです。
名前が複合主キーを構成し、名前の 1 つに依存するデータを持っていない限り、そのレベルに正規化する必要はありません (たとえば、姓が Plummer の人はデータベースについて何も知りません)。その場合、正規化しないと、第 2 正規形に違反します。
私は一般的な回答に同意します。あなたはそうしないでしょう。
ただし、1 つ頭に浮かぶのは、圧縮です。10 億人がいて、名の 60% が 5 つの非常に一般的な名前から抽出されていることがわかった場合、トリッキーなビット操作を使用してサイズを大幅に縮小できます。また、非常にカスタマイズされたデータベース ソフトウェアも必要になります。
しかし、これは正規化を目的としたものではなく、単なる圧縮です。