データベースを設計する際、常に第4正規形を目指すべきですか？データベースの3番目の通常の形式は大丈夫ですか？
3番目の正規形が私のビジネスドメインに近いと感じます。
たとえば、PartNumberという表があります。私のビジネスドメインでは、それはユニークなキーであり、2つの部分が同じ番号を持つことはありません。しかし、これはVARCHARです。主キーをVARCHARに入れて、それを他のテーブルへの外部キーとしてリンクすることは、私にとって大きな匂いです。
代わりにどこかに自動インクリメントIDを付ける必要がありますか？私はすぐにその点を見ていないし、多くのコードを複雑にする。
これはデータベースによって異なります。あなたのPKとしてvarcharフィールドを使用すると、MySQLのDBストレージとインデックスのスペースが無駄になります（たとえば）。パーツ番号にテーブルと一意の整数IDを付けることは、あまり純粋ではないように見えるかもしれませんが、そのようなことはパフォーマンスの面で必要となることがあります。
（そしてさらに、私は、これはあなたのビジネスロジックでの可能性はない可能性がある疑いがあるものの、それは、必要に応じて一つの場所に製品番号を更新することができません。）
あなたの質問は4NFについて尋ね一方で、あなたの特定の状況はそうではありません。 VARCHARフィールドを主キーとして使用するとが間違っているである場合、それが比較的小さい場合は代理キーではなくそのキーを使用することをお勧めします。
4NFに戻って - Wikipedia's exampleから、これは、多くの場合、ちょうど当然のことではないでしょうか。それは確かに4NFのために努力することを傷つけることはできません - 同時に非正規化がその場所を持っています。
ユーザは部品番号を編集できますか？もしそうなら、これはプライマリキーとして使用するのには良い引数です。一般的な経験則として、変更されたPKをDBを介して複製することはかなり高価になる可能性があるため、PKはユーザーが編集できないようにする必要があります。
また、2つの部分が同じ番号を持つことはありませんか、または2つの部分が同じ番号を持つことはできません。部分は同じ番号を持つことができますか？それが後者の場合、あなたは同じ長い2つの部品番号で終わるかもしれない長い歴史を守る必要がありますか？
データベースが少なくともBoyce-Codd Normal Formまたは理想的にはFifth Normal Formであることを目指します。 3NFは、それがそうでなければ5NFによって満たされないようにすることが重要である依存関係がある場合にのみ考慮してください。
4NFは、あなたのキーにvarcharまたは整数を使用するかどうかとは関係がありません。私はあなたがそれがなぜ起こったと思われるかわかりません。
データを正規化する方法を学ぶには数週間かかります。正規化の規則を無視する時期を知るには、数カ月、場合によっては数年かかることがあります。もちろん、正規化のルールを無視すると、結果が出ます。正規化を徹底的に学ぶならば、その結果があることがわかります。
場合によっては、他のデザインパターンに従う利点と比べて、ある特定の標準形に付着しないことの結果は軽いことがあります。たとえば、OLAPデータベースまたはデータウェアハウスを構築する場合、スタースキーマまたはスノーフレークスキーマは完全正規化よりも生産性が高いことがあります。
OLTPデータベースの場合、私はBoyce-Coddの標準形式を目指す傾向があり、4番目または5番目の正規形から逸脱したために発生する修正異常を処理する傾向があります。しかし、それは本当に事件に依存します。
また、IDは変更しないでください。 –