SQL計算フィールド効率

Question

データベースにはGUIDが主キーとして格納されていますが、これは複数のシステム間で一意性を強制するためです。あなたは

​​

のような選択を行うので、もし私は、計算フィールドを追加したテーブルが少し優しいようにするには

（ええ、私はテーブルごとに行あたり16のバイトがオーバーヘッド他のオプションが、同社の選択肢があります知っています）あなたは外部キーを持つ列を取得するだけでなく、関連するフレンドリーなフィールドを取得します。

CompanyGUID（ストアドフィールド）、会社名（計算フィールド）

計算フィールドのようなスカラー関数を経由して実行します：

CREATE FUNCTION [mySchema].[udf_CompanyNameFromGUID] (@GUID UNIQUEIDENTIFIER) 
RETURNS NVARCHAR(MAX) 
AS 
    BEGIN 
     DECLARE @Return NVARCHAR(MAX) 
     SELECT @Return = CompanyName 
     FROM mySchema.Companies 
     WHERE CompanyGUID = @GUID 
     RETURN @Return 
    END 

私は、これらのルックアップが主キー/クラスタ化に対して常にあることを指摘すべきですインデックスは個々に私が作ることができるほど速いです。

これは、問題を追跡しているときに大きな利点がありますが、大きなテーブルにクエリを実行すると、主な使用効率に影響はありません（計算されたフィールドはクエリされないため、影響はありません）ルックアップを行うにはしばらく時間がかかります。私は探している余分なデータを犠牲にしたくないので、テーブルに直接格納したくない（データの無駄遣いとメンテナンスが必要になる）。私は各テーブルのビューを構築することを考えましたが、それは過剰なもののように思え、むしろその努力を倍増させる必要はありません。

私はこのように働く唯一の人ではないと確信しています。誰かがこれを行うより効率的な方法を持っているかどうか知りたいのですが？これらのフィールドは、データベースを直接見ている人だけが使用し、すべてのストアドプロシージャなどはすべて索引付きリンクなどで完全にコーディングされています。大きな問題ではありませんが、もっと良い解決策があればそれを聞いてみたいと思います。

ありがとうございます。

Answer 1

私の提言：companyGUID列の場合

1. 、あなたがNEWSEQUENTIALID代わりのNEWIDを生成して使用することができ、それは断片化を低減します。インデックスのパフォーマンスを向上させます。
2. PERSISTEDオプションを追加することで、CompanyName列を永続化させることができます。

Answer 2

あなたの主なパフォーマンスの問題は、検索によって引き起こされたものではなく、SCALAR FUNCTIONが原因です。

スカラ関数はすべての行で呼び出され、単独ではありませんが、パフォーマンスに大きな影響を及ぼす行数に乗算されます。

viewてもよいあなたのケースでのソリューションです：

：それはあなたがビューを使用するときに拡大し、ビュー内だけ mySchema.Companiesを使用して、テーブルのJOINされるコードだけだとして、それは追加のスペースを必要としません。

create view dbo.MyView as 
select * -- put here your columns of interest including CompanyName 
from dbo.YourTable 
    join mySchema.Companies 
     on CompanyGUID = @GUID;