2

ビューを作成するとき、異なるテーブルの複数の列に基づいてビューを作成できます。ルックアップテーブルを作成する場合、別のテーブルから顧客の詳細を取得するために、あるテーブルからの情報(たとえば、注文テーブルの外部キー)が必要です。必要なすべてのデータを確実に取得するためのパラメーターを持つビューを作成できます。また、私が読んでいるものから、ルックアップテーブルを作成することもできます。この場合の違いは何ですか?ルックアップテーブルはいつ選択する必要がありますか?これが悪い質問ではないことを願っています。私はまだdbにはあまり興味がありません;)。

4

5 に答える 5

3

ビューを作成すると、クエリの時点でのデータの「ライブ」表現が得られます。これは、すべてのクエリの値を決定する必要があるため、サーバーの負荷が高くなるという犠牲を伴います。これは、テーブルサイズ、データベースの実装、およびビュー定義の複雑さによっては、コストがかかる可能性があります。

一方、ルックアップテーブルは通常「手動で」入力されます。つまり、ルックアップテーブルに対するすべてのクエリで、複数のテーブルから値をフェッチするためのコストのかかる操作が発生するわけではありません。代わりに、基になるデータが変更された場合に、プログラムがルックアップテーブルの更新を処理する必要があります。

通常、ルックアップテーブルは、めったに変更されないものに役立ちますが、頻繁に読み取られます。一方、ビューは実行に費用がかかりますが、最新のものです。

于 2010-03-10T14:14:55.727 に答える
2

「ルックアップテーブル」の使い方は少しおかしいと思います。通常の用語では、ルックアップテーブルはコードまたは参照データテーブルです。これは、CODEとDESCRIPTIONまたはコード拡張で構成されている場合があります。このようなテーブルの目的は、CUSTOMER_TYPEやPRIORITY_CODEなど、制限された列に許可された値のリストを提供することです。このカテゴリのテーブルは、変更されることはほとんどないため、「スタンディングデータ」と呼ばれることがよくあります。ルックアップテーブルでこのデータを定義することの価値は、外部キーで使用したり、ドロップダウンと値のリストにデータを入力したりできることです。

あなたが説明しているのは、わずかに異なるシナリオです。

別のテーブルから顧客の詳細を取得するには、あるテーブルの情報(たとえば、注文テーブルの外部キー)が必要です。

これらのテーブルは両方ともアプリケーションデータテーブルです。顧客レコードと注文レコードは動的です。これで、Customerテーブルから追加のデータを取得して、注文データと一緒に表示することが明らかに有効になりました。その意味で、Customerは「ルックアップテーブル」です。Orderの外部キーによって参照される主キーがあるため、より適切にはOrderの親テーブルです。

必ず、注文と顧客の間の結合ロジックをキャプチャするためのビューを作成してください。このようなビューは、複数の場所で同じ結合テーブルを使用するアプリケーションを構築する場合に非常に役立ちます。

于 2010-03-10T14:56:54.067 に答える
1

ルックアップテーブルの例を次に示します。陪審員を追跡するシステムがあります。テーブルの1つはJurorStatusです。この表には、陪審員の有効なStatusCodeがすべて含まれています。

コード:値
WS:サービスを提供します
PP:延期された
EM:言い訳軍隊
IF:不適格な重罪

これは、有効なコードのルックアップテーブルです。

ビューはクエリのようなものです。

于 2010-03-10T14:51:54.107 に答える
0

必要なものを正確に取得するためのSQLクエリの記述方法を学ぶだけです。ビューを作成する必要はありません!多くの場合、ビューを使用するのは適切ではありません。特に、他のビューに基づいてビューを作成し始めると、パフォーマンスが低下します。クエリ作成の省略形としてビューを使用しないでください。

于 2010-03-10T15:18:28.373 に答える
0

このチュートリアルを読むと、ルックアップテーブルが必要なときに役立つ情報が見つかる場合があります。

SQL:ルックアップテーブルの作成

于 2010-03-10T14:16:22.037 に答える