私はすべての悪の根源はここから始まると言うでしょう：
where acl.ToIds().Contains(r.PersonOrGroupID)
これacl.ToIds().Contains(...)はサーバー側では解決できない式であるため、visibleクエリはクライアント側で（非常に非効率的に）解決する必要があります。さらに悪いことに、結果はクライアントに保持する必要があります。表示されている予定（予定フィールド、役割、メモ）ごとに、個別のクエリをサーバーに送信する必要があります。自分のやり方があれば、ACLリストをテーブル値パラメーターとして受け入れ、サーバー側ですべての結合/フィルタリングを実行するストアドプロシージャを作成します。
私はこのスキーマから始めます：
create table Appointments (
AppointmentID int not null identity(1,1),
Start DateTime not null,
[End] DateTime not null,
Location varchar(100),
constraint PKAppointments
primary key nonclustered (AppointmentID));
create table AppointmentRoles (
AppointmentID int not null,
PersonOrGroupID int not null,
Role int not null,
constraint PKAppointmentRoles
primary key (PersonOrGroupID, AppointmentID),
constraint FKAppointmentRolesAppointmentID
foreign key (AppointmentID)
references Appointments(AppointmentID));
create table AppointmentNotes (
AppointmentID int not null,
NoteId int not null,
Note varchar(max),
constraint PKAppointmentNotes
primary key (AppointmentID, NoteId),
constraint FKAppointmentNotesAppointmentID
foreign key (AppointmentID)
references Appointments(AppointmentID));
go
create clustered index cdxAppointmentStart on Appointments (Start, [End]);
go
そして、次のように任意のACLの予定を取得します。
create type AccessControlList as table
(PersonOrGroupID int not null);
go
create procedure usp_getAppointmentsForACL
@acl AccessControlList readonly,
@start datetime,
@end datetime
as
begin
set nocount on;
select a.AppointmentID
, a.Location
, r.Role
, n.NoteID
, n.Note
from @acl l
join AppointmentRoles r on l.PersonOrGroupID = r.PersonOrGroupID
join Appointments a on r.AppointmentID = a.AppointmentID
join AppointmentNotes n on n.AppointmentID = a.AppointMentID
where a.Start >= @start
and a.[End] <= @end;
end
go
100万の予定でこれを試してみましょう。まず、テーブルにデータを入力します（約4〜5分かかります）。
set nocount on;
declare @i int = 0;
begin transaction;
while @i < 1000000
begin
declare @start datetime, @end datetime;
set @start = dateadd(hour, rand()*10000-5000, getdate());
set @end = dateadd(hour, rand()*100, @start)
insert into Appointments (Start, [End], Location)
values (@start, @end, replicate('X', rand()*100));
declare @appointmentID int = scope_identity();
declare @atendees int = rand() * 10.00 + 1.00;
while @atendees > 0
begin
insert into AppointmentRoles (AppointmentID, PersonOrGroupID, Role)
values (@appointmentID, @atendees*100 + rand()*100, rand()*10);
set @atendees -= 1;
end
declare @notes int = rand()*3.00;
while @notes > 0
begin
insert into AppointmentNotes (AppointmentID, NoteID, Note)
values (@appointmentID, @notes, replicate ('Y', rand()*1000));
set @notes -= 1;
end
set @i += 1;
if @i % 10000 = 0
begin
commit;
raiserror (N'Added %i appointments...', 0, 1, @i);
begin transaction;
end
end
commit;
go
それでは、今日の数人の予定を見てみましょう。
set statistics time on;
set statistics io on;
declare @acl AccessControlList;
insert into @acl (PersonOrGroupID) values (102),(111),(131);
exec usp_getAppointmentsForACL @acl, '20100730', '20100731';
Table 'AppointmentNotes'. Scan count 8, logical reads 39, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Appointments'. Scan count 1, logical reads 9829, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'AppointmentRoles'. Scan count 3, logical reads 96, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table '#25869641'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 63 ms, elapsed time = 1294 ms.
SQL Server Execution Times:
CPU time = 63 ms, elapsed time = 1294 ms.
1.2秒（コールドキャッシュでは、ウォームキャッシュでは224ミリ秒になります）。うーん、それはあまり良くありません。問題は、予定表でヒットした9829ページです。これを改善するために、両方のフィルタリング基準（aclとdate）を同時に使用したいと思います。おそらくインデックス付きのビューですか？
create view vwAppointmentAndRoles
with schemabinding
as
select r.PersonOrGroupID, a.AppointmentID, a.Start, a.[End]
from dbo.AppointmentRoles r
join dbo.Appointments a on r.AppointmentID = a.AppointmentID;
go
create unique clustered index cdxVwAppointmentAndRoles on vwAppointmentAndRoles (PersonOrGroupID, Start, [End]);
go
alter procedure usp_getAppointmentsForACL
@acl AccessControlList readonly,
@start datetime,
@end datetime
as
begin
set nocount on;
select ar.AppointmentID
, a.Location
, r.Role
, n.NoteID
, n.Note
from @acl l
join vwAppointmentAndRoles ar with (noexpand) on l.PersonOrGroupID = ar.PersonOrGroupID
join AppointmentNotes n on n.AppointmentID = ar.AppointMentID
join Appointments a on ar.AppointmentID = a.AppointmentID
join AppointmentRoles r
on ar.AppointmentID = r.AppointmentID
and ar.PersonOrGroupID = r.PersonOrGroupID
where ar.Start >= @start
and ar.Start <= @end
and ar.[End] <= @end;
end
go
Appointmentsのクラスター化されたインデックスをおそらくより有用なAppointmentIDに変更することもできます。
drop index cdxAppointmentStart on Appointments;
create clustered index cdxAppointmentAppointmentID on Appointments (AppointmentID);
go
これにより、77msの同じ日付範囲の同じ@aclリスト内の予定が返されます（ウォームキャッシュ上）。
もちろん、実際に使用するスキーマは、考慮されていない多くの要因によって異なります。しかし、これにより、適切なパフォーマンスを得るために今取るべき適切なアクションについてのアイデアが得られたことを願っています。テーブル値パラメーターをクライアント実行コンテキストに追加してプロシージャに渡すこと、およびLINQ統合は、読者の演習として残されています。