Question

I have the following table

EVENT_LOG:

EVENT_ID: pk, int, not null
TYPEID: fk, int, not null
CATEGORYID: fk, int, null
SOURCE: varchar(255), null
DESCRIPTION: varchar(4000), null
CREATED: datetime, null

We’ve been creating a report, and found that performance sucks. There aren’t any indexes aside from the clustered one. We could create them, but because this table is written to more than it is read from – there’s a counter weighing performance concern. For the reporting, I’m inclined to put indexes on every column because the source & description columns need to be searched for substrings.

We wondered if an indexed view (AKA materialized view) would be an option, where the indexed view would contain all the columns from the EVENT_LOG table but have the appropriate indexes created on the view. Would this get us the performance for reporting, while not impacting writes to the EVENT_LOG table?

Answer 1

An indexed view will cause the same issues as an index on the column, because indexed views require with schemabinding, which tie it to the table directly, disallowing you from changing/altering the schema of that table in any way, shape, or form. This includes resizing a column (e.g.-from varchar(50) to varchar(255)), changing a column’s data type (e.g.-from double to decimal(18,5)), etc. I’ve seen them cause a lot of unexpected headaches due to this fact.

My suggestion is to set up a stored procedure or SSIS package that will create a reporting table for you that’s run every hour or so. This way, you can index the ever-loving hell out of it and enjoy all the performance benefits that it produces. I shy against reporting from a live, in-progress system. I’ve actually yet to see the case where this is necessary. For reporting purposes, hour-old information is usually absolutely sufficient to get the job done.