0

セミナーの場所を含めるべきフィールドがあります。セミナーを開催することができます：

  • 社内
  • 別の都市で
  • 他の国で

最初はテーブルが1つしかなかったので、列挙型を使用しました。しかし、現在、マージできない3つのテーブルがあり、それらすべてにこの情報が含まれている必要があります。顧客は、このフィールドをカスタマイズして、将来オプションを追加または削除することを望んでいます。しかし、選択肢の数は限られており、おそらく5かそこらです。

さて、私の質問は、このフィールドに列挙型またはテーブルを使用する必要があるかどうかです。さらに重要なことに、列挙型とテーブルのどちらを使用するかを決定する適切な方法は何でしょうか。

PS：列挙型フィールドはデータベースから動的に取得されます。コードには埋め込まれていません。

4

3 に答える 3

1

一般的な経験則として、アプリケーションでは、次の場合に列挙型を使用します。

  1. あなたの価値観はめったに変化しません、そして
  2. 値はごくわずかです。

次の場合にルックアップテーブルを使用します。

  1. 値が頻繁に変わる、または
  2. 顧客は、値をリアルタイムで追加、変更、または削除できることを期待しています。
  3. たくさんの価値観があります。

列挙型の以前の基準が満たされている場合と、次の両方を使用します。

  1. アプリケーションの外部のツールを使用してデータについてレポートできる必要があります。
  2. 後で純粋なルックアップテーブルアプローチを採用するために、列挙型を削除する必要があるかもしれません。

カットオフポイントの値の数を適切にカットしたと思うものを選択する必要があります。10から15の間のどこかが提案されているとよく耳にします。

データベースエンジンによって提供される列挙型構造を使用している場合でも、最初の2つのルールグループが適用されます。

あなたの特定のケースでは、私はルックアップテーブルを使います。

于 2012-04-24T15:12:55.110 に答える
0

その場合に要素が固定されている場合は、列挙型を使用する必要があります。可変データの場合は使用しenumないでください。そのような場合tableは、より望ましいです。

あなたの場合、テーブルは大丈夫だと思います。

于 2012-04-24T14:53:02.183 に答える
0

私は、列挙型が無駄がなく、わずかに高速であり、合理的に使用された場合にデータベースの複雑さを軽減することについての上位の回答に同意します（つまり、多くの急速に変化する値がありません）。

しかし：考慮すべきいくつかの大きな警告があります：

  • ENUMデータ型は標準SQLではなく、MySQLを超えて、他の多くのDBMSがそれをネイティブにサポートしていません。PostgreSQL、MariaDB、およびDrizzle（後者の2つはとにかくMySQLのフォークです）は、私が知っている3つだけです。あなたまたは他の誰かがデータベースを別のシステムに移動したい場合、誰かがあなたのすべての巧妙なENUMを処理するために、移行手順にさらにステップを追加する必要があります。（ http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/のソースおよびさらに多くのポイント）

  • ENUMSは、SQL標準ではないため、DoctrineなどのほとんどのORMではサポートされていません。したがって、プロジェクトでORMを使用することを検討したり、Doctrine Migrations Bundleとして何かを使用 したりする場合は、複雑な拡張バンドル（私が試したもの）を作成するか、Postgresqlなどの既存のものを使用することになります。列挙型の疑似サポートをさらに追加することはできません。列挙型をチェック制約付きの文字列型として扱うことによって。例：

    CREATE TABLE test（id SERIAL NOT NULL、pseudo_enum_type VARCHAR（255）CHECK（pseudo_enum_type IN（'value1'、'value2'、'value3'））、.. ..

したがって、もう少し複雑な設定で列挙型を使用することの利点は、実際にはゼロ未満です。

真剣に：私が絶対にそうする必要がない（そして私がそうしない）なら、私は常にデータベース内の列挙型を避けます。

于 2017-04-13T10:23:50.897 に答える