CREATE TABLE [dbo].[EOrderReminderConsent]( [Id] [int] IDENTITY(1,1) NOT NULL, [BookingId] [nvarchar](50) NOT NULL, [ShowTime] [datetime] NOT NULL, [Email] [nvarchar](150) NULL, [EmailSend] [smallint] NULL, [RetryStatus] [smallint] NULL, CONSTRAINT [PK_EOrderReminderConsent] 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]
So The booking ID is there but rarely used in query selects.
The main use is on the email and ShowTime
Emails are almost always different, ShowTime is different by shows. I mean, suppose we have a show starting at 16:10 and another one at 18:00 then a data sample would be like this:
So email constantly changes and session from show to show.
The select would be select email where showtime = sometime
So what seems correct to me is create and index on showtime and included column on email.
That is, I'm note sure about the showtime as it is not a different value always.
Also another question. Suppose that we delete this rows when we send an email, 30 minutes before the show starts. Some shows of course may have been pre paid and the showtime can be days, even weeks or month away, so we would maintain values in the table. But I do not expect the maintained values to be more than 100.000-200.000. Is that worth using an index, considering that this table insert values constantly, so we are slowing the insertions down by using indexes.