基本的に 2 種類のデータを持ち、常に 1 対 1 の関係を持つ非常に単純なデータベース (mysql) を作成しています。
イベント
スポンサー
都市は頻繁に複製されますが、このような単純なデータベース スキーマに都市テーブルを用意することに本当に価値があるのでしょうか?
データベースは、Web サイトのスクリーンスクレイピングによって作成されます。このサイトでは、都市フィールドはドロップダウンからの選択によって入力されるため、タイプミスなどはなく、レコードを都市テーブルと簡単に一致させることができます。私のデータベースのユーザーが頻繁に都市で検索する場合でも、あまり意味があるかどうかはわかりません.
データベースを今すぐ正規化します。
大量のデータを正規化するよりも、正規化されたデータに対するクエリを最適化する方がはるかに簡単です。
今は単純だとおっしゃいますが、これらのものは成長する傾向があります。適切に設計すれば、適切な設計と将来の証明の経験を得ることができます。
あなたは物事を間違った方法で見ていると思います-そうしない正当な理由がない限り、常に正規化する必要があります。
データの整合性を維持するためにアプリケーションを信頼することは、不必要なリスクです。ドロップダウンで選ぶのでデータが統一されているとおっしゃっていますね。誰かがフォームをハッキングしてデータを変更した場合、またはコードが誤って同じ名前のクエリ文字列パラメーターを許可した場合はどうなるでしょうか?
直接的な答え：問題が比較的単純であるという理由だけで、それを単純に保つために何かをしない理由はありません。手よりも足で歩く方がはるかに簡単です。「ああ、半マイル行けばいい、それは短い距離なので、手で歩いたほうがいい」と言ったことは今まで覚えていません。
より長い答え：都市の名前以外の情報を保持しておらず、都市の事前設定リストがない場合（たとえば、ドロップダウンを作成するため）、スキーマはすでに正規化されています。都市名以外の都市テーブルには何が含まれますか？（オハイオ州デイトンとテネシー州デイトンなど、異なる州に同じ名前の2つの都市がある可能性があるため、州は市に依存できないと思います。）関連する正規化のルールは「非キー依存関係なし」です。キーではないデータに依存するデータがあります。たとえば、各都市の緯度と経度がある場合、このデータは同じ都市を参照するすべてのレコードで繰り返されます。その場合、緯度と経度を保持するために別の都市テーブルを作成することをお勧めします。もちろん、「都市コード」を作成することもできます これは、都市テーブルにリンクする整数または省略形です。しかし、都市に関する他のデータがない場合、これがどのように何かを得るのかわかりません。
技術的には、CityはVenueに依存していると思います。会場が「ロックフェラーセンター」の場合、それは都市がニューヨークでなければならないことを意味します。しかし、会場がオプションの場合、これは問題を引き起こします。1つの可能性は、会場名、都市、および州をリストする会場テーブルを用意することです。会場を指定しない場合は、各都市に「未指定」を設定します。これは教科書の方が正しいでしょうが、実際には、ほとんどの場合、venuを指定しないと、ほとんど得られません。ほとんどの場合、venuを指定する場合は、おそらくそれは良い考えです。
ああ、そして、イベントとスポンサーの間には本当に1：1の関係がありますか？イベントに複数のスポンサーを含めることはできないと私は信じています。（実際には、複数のスポンサーによるイベントがたくさんありますが、おそらくあなたの目的のために、「プライマリスポンサー」などだけを気にします。）しかし、スポンサーが複数のイベントを開催することはありませんか？それはありそうもないようです。
ユーザーのドロップダウン ボックスにデータを入力する都市データはどこから取得されますか? そのためのテーブルが欲しくないですか？
Location を都市と州を含む 1 つの属性として扱っているようです。都市や州ではなく、州だけでイベントを並べ替えたり分析したりしたいとしますか? 状態の属性がない場合、これを行うのは難しい場合があります。論理的には、州は都市テーブルに属していると思いますが、それは都市をどのように識別したいかによって異なります。
正規化について学習することに興味がある場合は、正規化しないとどうなるかを学ぶ必要があります。正規形（1NFを超える）ごとに、有害な冗長性の結果として発生する更新異常があります。
多くの場合、更新の異常を回避するようにプログラムすることが可能であり、場合によっては、常に最終的な程度に正規化するよりも実用的です。
場合によっては、正規化に失敗したり、アプリケーションをプログラムして補正できなかったりするために、データベースが一貫性のない状態になる可能性があります。
あなたの例では、私が思いつくことができる最高のものは、一種の不完全な仮説です。都市の名前のつづりが1行で間違っていても、他のすべての行では正しくつづられている場合はどうなりますか。市とスポンサーごとに要約するとどうなりますか？出力はエラーを反映し、1つのグループを2つのグループに分割します。良くも悪くも、都市がデータベースに1回だけ記述されていれば、もっと良いかもしれません。名前のつづりが間違っていても、少なくとも要約のグループ化は正しいでしょう。
これは、nromalizeする価値がありますか？ねえ、それはあなたのプロジェクトであり、私のものではありません。あなたが決める
先に進んで正規化してみませんか？あなたは、利益を上回る正規化のかなりのコストがあるかのように書きます。後で正規化するよりも、データを入力する前に通常の形式で設定する方が簡単です。
また、あなたの1対1の関係についても疑問に思います。単純に、イベントに複数のスポンサーがいる場合や、スポンサーが複数のイベントに関与している場合があると思います。しかし、私はあなたのビジネスロジックを知りません...
ETA： なぜこれまで気づかなかったのかわかりませんが、データベースの正規化を本当に嫌がり、イベントとスポンサーの間には常に1対1の関係があることを知っているのなら、なぜですか別のテーブルにスポンサーがいますか？
正規化とは何か、なぜそれを行うのかについて少し混乱しているようです。
答えは、データ入力中のエラーを防ぎたいかどうかにかかっています。その場合、VENUES テーブルが必要になります。
VENUES
City
State
VenueName
CITIES および STATES テーブルと同様に。(注: 私は、同じ都市が同じ州 (通常は小さな町) で複数回発生する状況を見てきました。そのため、CITY/STATE は一意のダイアドを構成しません。通常、曖昧さをなくすための郵便番号があります。)
データ入力オペレーターが、実際には SF CA にある NY NY の会場に入る状況を防ぐには、会場エントリを検証して、そのような会場がレコードで提供された市/州に存在するかどうかを確認する必要があります。
次に、CITY/STATE を必須にする必要があり、トランザクションをロールバックしてエラーを処理するコードを記述する必要があります。
この種の正確さを強制することに関心がない場合は、CITY テーブルと STATES テーブルも実際には必要ありません。