ソフト削除 - iSDELETEDフラグまたは独立したジョイナーテーブルを使用しますか?
-
28-10-2019 - |
質問
柔らかい削除または別のジョイナーテーブルにフラグを使用する必要がありますか?どちらがより効率的ですか?データベースはSQL Serverです。
背景情報
しばらく前に、DBコンサルタントが入ってきて、データベーススキーマを見ました。レコードをソフト削除すると、適切なテーブルにisdeletedフラグを更新します。フラグを使用する代わりに、削除されたレコードを別のテーブルに保存し、それがより良いので結合を使用することが示唆されました。私はその提案をテストにしましたが、少なくとも表面上では、追加のテーブルと結合は、フラグを使用するよりも高価に見えます。
初期テスト
このテストを設定しました。
2つのテーブル、例と削除Example。 iSDELETED列に非クラスター化されたインデックスを追加しました。
私は3つのテストを行い、次の削除/非削除比率で100万のレコードをロードしました。
- 削除/非削除
- 50/50
- 10/90
- 1/99
結果-50/50
結果-10/90
結果-1/99
データベーススクリプト、参照、例、削除、deletedexample、およびindexなど。たとえばisdeleted
CREATE TABLE [dbo].[Example](
[ID] [int] NOT NULL,
[Column1] [nvarchar](50) NULL,
[IsDeleted] [bit] NOT NULL,
CONSTRAINT [PK_Example] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Example] ADD CONSTRAINT [DF_Example_IsDeleted] DEFAULT ((0)) FOR [IsDeleted]
GO
CREATE TABLE [dbo].[DeletedExample](
[ID] [int] NOT NULL,
CONSTRAINT [PK_DeletedExample] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[DeletedExample] WITH CHECK ADD CONSTRAINT [FK_DeletedExample_Example] FOREIGN KEY([ID])
REFERENCES [dbo].[Example] ([ID])
GO
ALTER TABLE [dbo].[DeletedExample] CHECK CONSTRAINT [FK_DeletedExample_Example]
GO
CREATE NONCLUSTERED INDEX [IX_IsDeleted] ON [dbo].[Example]
(
[IsDeleted] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
解決
あなたがそれを示しているように見える数字 私の最初の印象 正しかった:このデータベースに対する最も一般的なクエリがフィルタリングすることである場合 IsDeleted = 0
, 、特にインデックスを賢明に使用する場合は、単純なビットフラグでパフォーマンスが向上します。
削除されていないデータを個別にクエリすることが多い場合は、削除されたアイテムのテーブルと、同一のフィールドを持つ未定のアイテム用のテーブルと別のテーブルを用意することで、パフォーマンスの向上を確認できます。しかし、このようなデータを非正規化することは、パフォーマンスの増加よりもコードメンテナンスコストのコストがはるかに多くなることが多いため、このようにデータを非正規化することはめったにありません。
他のヒント
私はSQLの専門家ではありませんが、私の意見では、それはすべてデータベースの使用頻度に依存します。データベースが多数のユーザーからアクセスされ、効率的である必要がある場合、別のイスデレットテーブルの使用が適切です。より良いオプションは、生産時間中にフラグを使用することであり、毎日/毎週/毎月のメンテナスの一部として、すべてのソフト削除レコードをiSDELETEDテーブルに移動し、ソフト削除レコードの生産テーブルをクリアできます。両方のオプションの混合物は良いものになります。