場合によってはあらかじめ定義されていることもあり、時にはカスタムの値のデータベース設計

Question

私が設計しているWebサイトの一部には、事前定義された値とカスタム値を指定するオプションの両方があるセクションがあります。

より簡単な例として、値が「スポーツ」であり、アプリケーションに事前定義されたスポーツがあると仮定しますが、一部のユーザーは自分が出てくるすべてを予測できないため、ユーザーは他のユーザーが入力したスポーツにアクセスすることはできません。

事前定義のスポーツとカスタムスポーツを同じテーブルに保存する必要がありますか？この場合、そのテーブルのuser_idカラムをnullにするか、あらかじめ定義されたスポーツのユーザとユーザIDを作成する必要があります。

名前でスポーツを検索するときは、ほとんどの場合、定義済みのスポーツとユーザー自身のカスタムスポーツの両方を検索したいので、事前定義されたスポーツとカスタムスポーツが分かれていれば、テーブル。

一方、それらが分離されていると、sport_idに基づいて外部キー関係を指定することが難しくなります。

このような状況にアプローチするにはどうすればよいでしょうか？

Answer 1

テーブルに定義済み値とカスタム値の両方を含む問題はありません（後で何かを行う必要がある場合は、ビットフラグを使用して「カスタム」を指定できます）。また、その表の主キーとしてID値を簡単に指定できるため、外部キー関係の指定に問題はないはずです。

唯一の問題は、冗談と間違いです。

Answer 2

私はこれを多対多関係として実装します。 表1 - スポーツ（sport_id、sport_name、system_defined） 表2 - ユーザー（USER_ID、USER_NAME） 表3 - users_x_sports（USER_ID、sport_id）

スペースが貴重でない場合、users_x_sportsテーブルはへのユーザーの参加ユーザー定義のスポーツとシステム定義のスポーツ。

スペースに余裕がある場合は、UNIONを使用してシステム定義およびユーザー定義のスポーツを検索します。ユーザーをユーザー定義のスポーツにリンクするだけです。

スポーツを標準化して重複を減らすことで、余分なリンクをusers_x_sportsテーブルで補うことができます。