イベント管理サイトのデータベースを設計しています。会場の表とイベントの表があります。各イベントは会場内にあり（会場のIDを格納します）、各会場は都市内にあります。都市が会場テーブルのフィールドである場合（スペルミスにより都市が重複する可能性があります）、または都市のテーブル（それぞれIDと名前が付いている）がある場合は、都市ごとにイベントを検索できる必要があります。都市と会場（cityid、venueid）をリンクする1対多のテーブル？
これはかなり基本的な質問ですが、追加の結合と追加の2つのテーブルがそれに値するかどうかはよくわかりません。
前もって感謝します
[編集]@tvanfosson：各会場が単一の都市に関連付けられているため、多対多から1対多に変更されました。
別のテーブルを使用します。これにより、ドロップダウンや自動提案フィールドにデータを入力するための都市のマスター リストが作成され、文字列の代わりに ID を重複して格納することでスペースを節約できます。会場が 100 万あり、都市が 1,000 しかない場合、ストレージとクエリ速度の両方の点で大幅な節約になります。これは、パフォーマンスを低下させる原因となるオフディスクの読み取りをそれほど必要としないためです。
おそらく、都市だけでなく州も指定する必要があります (会場がどのスプリングフィールドにあるかがわかるようにするため)。
都市のセットは固定されており、比較的小さく、更新される可能性は低いと思います（スペルについては、いつでも新しい都市を追加できます）。この場合、XMLファイルからフィードされたドロップダウンから都市を選択し、選択した値をデータベースの列に格納する機能を提供します。間違った入力の可能性があるため、ユーザー提供の入力の使用は避けます。
都市が州にある郡にある、より階層的な構造の場合は、同じ名前の都市を複数の場所に置くことができるため、テーブルベースのアプローチの方が適切な場合があります。この場合、カスケードドロップダウンは、XMLを使用するよりもデータベースクエリを使用して管理する方が簡単だと思います。
注：状況に大きく依存するため、おそらく「正しい」答えはありません。
都市の列を含むアドレステーブルを用意することを検討する価値があるかもしれません。
解決策は、他の機能が何であるか、およびデータベースが将来他の機能に使用されるかどうかによって異なります。
これは主観的な選択でもあります。私の意見では、個別の都市テーブルを持つことは、おそらくわずかに正規化されすぎています。
都市と会場をリンクする多対多の関係を、各都市のすべての会場を格納できる追加のテーブル（venue_cityなど）を使用して1対多の関係に変換し、テーブルイベントとvenue_cityを格納するテーブルvenue_cityをリンクしますテーブルイベントへのID。
会場に都市名を保存しないでください。代わりに、city-idを割り当て、それを会場に保存します。参加して特定の都市のイベントを見つける前に、都市名から都市IDを解決し、それを参加基準として使用します。これは、利便性とパフォーマンスの向上のためにストアドプロシージャに実装できます。
私があなたの状況を正しく理解していれば、州を含む市の表は必須です。必要に応じて新しい都市/州を追加できます (追加する前にテーブルに存在することを確認してください)。これははるかに効率的であり、都市名の重複を避けることができますが、スペルミスがあります。
おそらく都市のテーブルが必要です。今は必要ない場合でも、郵便番号を追加したり、都市を州に含めたりする必要があるかもしれません。