2008-10-29 117 views
0

SQL Server 2005的更新「現場訪問」行多次:注意事項在會議

我有一個SiteVisit行其中包含有關用戶訪問的信息,例如HttpRefer,不管他們是否下了訂單,瀏覽器等

目前爲報告我加入此表SiteEvent其中包含訪問每個「部分」的信息。然後這會產生一個視圖,顯示每個用戶訪問了多少部分的統計信息。顯然,這不是一個可持續的方式來做到這一點,現在我正在做一些重構。

我想將SectionsVisited列從我的視圖移動到SiteVisit中的實際列。然後,我會在每次用戶訪問該會話時更新它。

現在我的實際問題: 在每次會話更新一行多次時需要考慮哪些因素。顯然,我有一個索引行(目前由GUID索引,以防止大多數惡意篡改)。

我只想知道我應該做什麼非明顯的事情(如果有的話)。有什麼具體的事情我應該做的優化表或將SQL Server 2005幾乎照顧自己

注意:這是一個Flash網站,所以請不要只推薦一個跟蹤工具。我想做一些 '瘋狂'datamining並開發了這樣的跟蹤。這主要是爲了成爲一個數據庫問題,而不是「如何跟蹤」的問題。

請求表定義:

USE [RazorSite] 
GO 
/****** Object: Table [dbo].[SiteVisit] Script Date: 10/29/2008 14:35:56 ******/ 
SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER ON 
GO 
SET ANSI_PADDING ON 
GO 
CREATE TABLE [dbo].[SiteVisit](
    [SiteVisitId] [int] IDENTITY(1,1) NOT NULL, 
    [SiteUserId] [int] NULL, 
    [ClientGUID] [uniqueidentifier] ROWGUIDCOL NULL CONSTRAINT [DF_SiteVisit_ClientGUID] DEFAULT (newid()), 
    [ServerGUID] [uniqueidentifier] NULL, 
    [UserGUID] [uniqueidentifier] NULL, 
    [SiteId] [int] NOT NULL, 
    [EntryURL] [varchar](100) NULL, 
    [CampaignId] [varchar](50) NULL, 
    [Date] [datetime] NOT NULL, 
    [Cookie] [varchar](50) NULL, 
    [UserAgent] [varchar](255) NULL, 
    [Platform] [int] NULL, 
    [Referer] [varchar](255) NULL, 
    [RegisteredReferer] [int] NULL, 
    [FlashVersion] [varchar](20) NULL, 
    [SiteURL] [varchar](100) NULL, 
    [Email] [varchar](50) NULL, 
    [FlexSWZVersion] [varchar](20) NULL, 
    [HostAddress] [varchar](20) NULL, 
    [HostName] [varchar](100) NULL, 
    [InitialStageSize] [varchar](20) NULL, 
    [OrderId] [varchar](50) NULL, 
    [ScreenResolution] [varchar](50) NULL, 
    [TotalTimeOnSite] [int] NULL, 
    [CumulativeVisitCount] [int] NULL CONSTRAINT [DF_SiteVisit_CumulativeVisitCount] DEFAULT ((0)), 
    [ContentActivatedTime] [int] NULL CONSTRAINT [DF_SiteVisit_ContentActivatedTime] DEFAULT ((0)), 
    [ContentCompleteTime] [int] NULL, 
    [MasterVersion] [int] NULL CONSTRAINT [DF_SiteVisit_MasterVersion] DEFAULT ((0)), 
CONSTRAINT [PK_SiteVisit] PRIMARY KEY CLUSTERED 
(
    [SiteVisitId] 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 
SET ANSI_PADDING OFF 
GO 
ALTER TABLE [dbo].[SiteVisit] WITH CHECK ADD CONSTRAINT [FK_SiteVisit_Platform] FOREIGN KEY([Platform]) 
REFERENCES [dbo].[Platform] ([PlatformId]) 
GO 
ALTER TABLE [dbo].[SiteVisit] CHECK CONSTRAINT [FK_SiteVisit_Platform] 
GO 
ALTER TABLE [dbo].[SiteVisit] WITH CHECK ADD CONSTRAINT [FK_SiteVisit_Site] FOREIGN KEY([SiteId]) 
REFERENCES [dbo].[Site] ([SiteId]) 
GO 
ALTER TABLE [dbo].[SiteVisit] CHECK CONSTRAINT [FK_SiteVisit_Site] 
GO 
ALTER TABLE [dbo].[SiteVisit] WITH CHECK ADD CONSTRAINT [FK_SiteVisit_SiteUser] FOREIGN KEY([SiteUserId]) 
REFERENCES [dbo].[SiteUser] ([SiteUserId]) 
GO 
ALTER TABLE [dbo].[SiteVisit] CHECK CONSTRAINT [FK_SiteVisit_SiteUser] 

當前指標:

IX_CampaignId - non unique, non clustered 
IX_ClientGUID - Unique, non clustered  <-- this is how a user is identified for updates 
IX_UserGUID - non unique, non clustered 
PK_SiteVisit - (SiteVisitId column) - clustered 

回答

0

,我可以給是最好的建議:保持桌面小。

怎麼樣?有一張包含所有「實時」數據的表格,即活動會話。會話過期時:將數據移出到「歸檔」表或甚至另一個數據庫服務器以進行挖掘。

在「實時」表(會話ID)上只有很少的索引。您可以在「存檔」表中擁有所有需要的索引,以加快數據回覆速度。

+0

好主意。這是即時尋找的答案 – 2008-10-29 21:28:14