2

非トランザクションデータを含む約50個の小さなルックアップテーブルを備えたERPアプリケーションがあります。例としては、ItemTypes、SalesOrderStatusesなどがあります。非常に多くの異なるタイプとカテゴリおよびステータスがあり、新しいモジュールごとに新しいルックアップテーブルが追加されています。これらのテーブルからListオブジェクトを提供するサービスがあります。これらのテーブルには通常、2つの列（IdとDescription）のみが含まれます。それらには数行しかなく、最大で8〜10行です。

ID、Description、LookupTypeIDを使用してそれらすべてを1つのテーブルに配置することを考えています。この1つのテーブルで、50個のテーブルを取り除くことができます。いい考えですか？悪いアイデア？非常に悪い考えですか？

小さなルックアップテーブルを管理するための標準/ベストプラクティスはありますか？

4

6 に答える 6

1

一部の専門家の間では、単一の一般的なルックアップテーブルは避けるべき設計エラーです。少なくとも、パフォーマンスは低下します。その理由は、共通テーブルの複合主キーが必要であり、複合キーを介したルックアップは、単純キーを介したルックアップよりも時間がかかるためです。

Anith Senによると、これは避けるべき5つの設計エラーの最初のものです。この記事を参照してください：5つの単純な設計エラー

于 2012-07-19T06:30:31.710 に答える
1

Luceneのようなテキスト検索（つまりnosql）データベースにそれらを保存できます。彼らは途方もなく速いです。

私はこれを非常に効果的に実装しました。ただし、克服すべき初期設定がいくつかありますが、それほど多くはないことに注意してください。IDに対するLuceneクエリは、簡単に記述できます。

于 2012-07-19T06:34:05.320 に答える
1

データの整合性を気にする場合（そしてそうすべきです！）、ルックアップテーブルをマージすることは悪い考えです。

  • これにより、「クライアント」テーブルは、参照することを意図していないデータを参照できるようになります。たとえば、DBMSは、許可されるべきSalesOrderStatuses場所のみを参照することからユーザーを保護しません。これらは同じテーブルにあり、対応するFKを（簡単に）分離することはできません。ItemTypes
  • すべてのルックアップデータが同じ列とタイプを共有するように強制されます。

過度のJOINによるパフォーマンスの問題がない限り、現在の設計を維持することをお勧めします。

その場合、ルックアップテーブルで代理キーの代わりに自然キーを使用することを検討できます。このように、自然キーは外部キーを介して「クライアント」テーブルに「伝播」されるため、ストレージスペースが増える代わりに、JOINの必要性が少なくなります。たとえば、持っているのではなく、持っItemTypes {Id PK, Description AK}ているだけで、取得するためだけにItemTypes {Description PK}参加する必要はありません。これは、FKに自動的に伝播されます。ItemTypesDescription

于 2012-07-19T07:51:28.113 に答える
1

「1つの大きなルックアップテーブル」アプローチには、ばかげた値を許可するという問題があります。たとえば、「色：黄色」の車しかない場合、在庫にあるトラックの「色：黄色」などです。1つの大きなルックアップテーブル：「いいえ」と言ってください。

一方で、「2012モデルのCX300Rは赤でしたが、2010-2011モデルのCX300Rは青でした（モデルIDも色を示します）」などの場合を除いて、ルックアップテーブルの自然キーを使用します。

于 2012-07-19T21:07:38.130 に答える
0

従来、DBAに尋ねると、別々のテーブルが必要だと言われます。プログラマーに尋ねると、単一のテーブルを使用する方が簡単だと言われます。（ステータスの編集Webページを非常に簡単に作成できるため、1つのWebページを作成して、多くの類似したページではなく、別のLookupTypeIDを渡すだけです）

ただし、ORMを使用すると、さまざまなステータステーブルにアクセスするためのSQLとコードは実際には余分な労力ではありません。

私は両方の方法を使用しましたが、どちらも正常に機能します。単一のステータステーブルを使用するのが最も簡単であることを認めなければなりません。私はこれを小さなアプリとエンタープライズアプリに対して行いましたが、パフォーマンスへの影響はありませんでした。

最後に、これらの汎用ステータステーブルに通常追加するもう1つのフィールドは、OrderByフィールドです。これにより、必要に応じて、説明以外の名前でUIのステータスを並べ替えることができます。

于 2012-07-19T06:44:16.833 に答える
-1

私には良い考えのように聞こえます。IDとLookupTypeIDを複数属性の主キーとして使用できます。さまざまなLookupTypeIDがすべて何を表しているのかを知る必要があり、ゴールドとして優れている必要があります。

編集：標準/ベストプラクティスに関しては、正直なところ、答えはありません。私はSQL/データベース設計の1学期しか持っていなかったので、私はこの問題にあまりさらされていません。

于 2012-07-19T02:10:26.523 に答える