これを処理する方法については独自の考えがありますが、これについて別の見方があるかどうかを確認したいと思います。これに関する問題は、次のテーブル(サンプルテーブル)があることです
---------------------------------------------------------------------------------------
CREATE TABLE Account
(
AccountId int identity(1,1),
CreationDate datetime,
CONSTRAINT [PK_Account] PRIMARY KEY CLUSTERED
(
[AccountId] ASC
)WITH (FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE AccountSales
(
AccountSalesId int identity(1,1),
AccountId int,
CONSTRAINT [PK_AccountSales] PRIMARY KEY CLUSTERED
(
[AccountSalesId] ASC
)WITH (FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]
ALTER TABLE [dbo].[AccountSales] WITH CHECK ADD CONSTRAINT [FK_AccountSales_Account] FOREIGN KEY([AccountId])
REFERENCES [dbo].[Account] ([AccountID])
GO
ALTER TABLE [dbo].[AccountSales] CHECK CONSTRAINT [FK_AccountSales_Account]
GO
---------------------------------------------------------------------------------------
Account テーブルが 500 GB で、AccountSales が 1 TB であるとします。明らかな理由から、これらのテーブルを分割したいと思います。現在のロジックでは、データは日ごとに処理されるため、Account テーブルの日付フィールドで分割することは理にかなっていますが、AccountSales テーブルには日付フィールドがありません。また、データは異なるサーバーから異なる時間にロードされるため、ID と日付に関しては、両方のテーブルのデータは連続していません。同様のアカウントには次のデータがある場合があります
Id Date Server loaded from (not a column - just for display purposes)
--------------------------
1 1/1/2000 00:00 1
2 1/1/2000 01:00 1
3 1/1/2000 02:00 1
4 1/1/2000 00:00 2
5 1/1/2000 01:00 2
6 1/1/2000 0:300 1
Accounts テーブルについては、CreationDate にクラスター化インデックスを作成し、AccountId を一意の NC インデックスを持つ PK として設定することを考えていました。次に、日付で分割します。
ただし、AccountSales テーブルの処理方法については 100% 確信が持てません。id で処理した場合、Account テーブルと結合すると日付が正しく一致しないため、これを修正する方法がわかりません。
何か案は?これを処理する最善の方法は何ですか? さらに情報が必要な場合は、お知らせください。よろしくお願いします!