固定オプション用に個別のテーブルを作成する必要がありますか？

debugcn 投稿 Dev

マットウェーバー

以下に示すように、DBデザインの複数の場所で、必要に応じて「オプション」のテーブルを作成しています。例、RFPステージ。「完全」、「入札」などを保持します。

削除された質問のある時点で私に勧められたので、これを行っています。これはこれを行うための適切な方法ですか？または、可能性が5つ程度しかない場合、これらのオプションをテキストとして保存する必要がありますか？

バジルバーク

追加フィールド

If your list of possible values such as rfp_stage involves more than just a name, then you definitely want a look-up table added to your design. For example, to track a color used for "Complete" and another color for “Bidding”, then you need a second field color along with name on the rfp_stage look-up table.

Single field

If the name of each RFP stage is the only value, no such additional items such as color discussed above, then you may want to use a string column without any lookup table.

You could enforce a list of possible values in your app(s).

As a backup to the app’s enforcement, if you are using a powerful database system such as Postgres, you can define a domain of possible values and require the field to always have a value in that domain. Trying to add or update a row with an unexpected value will fail, with an error thrown by the database engine.

Handling changes to value

Then again, if there is any possibility of the names of any stage changing, such as “Bidding” changing to “Out for bid” (same meaning, different wording), then a look-up table is useful as a single place to update the wording. No need to perform a mass update of values across many rows.

Internationalization

同様に、各RFPステージの表示をローカライズする必要がある場合、たとえば「完了」と「入札」をフランス語または日本語で表示する場合は、ルックアップテーブルを追加する必要があります。ローカリゼーション文字列を保持するためのさらに別のルックアップテーブルがある可能性がありますが、それはこの回答の範囲外です。詳細については、StackOverflowおよびおそらくDBAStackExchangeを検索してください。

列挙型

最後に、データベース内の列挙型を、可能な各値を表す代用値として使用する人もいます。たとえば、「完了」の場合は「1」、「入札」の場合は「2」などです。行からのデータの読み取りが厄介で不便になるため、私は通常、このアプローチを自分で避けています。

環境

多くの設計上の決定と同様に、明確な黄金律はありません。コンテキストが重要です。

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集2021-06-2

コメントを追加

サインイン

分類Dev

Related 関連記事

記事