Antipatterns: Mixing Reporting and Data Entry functions. What the?

Could this smell any worse?

The current project I'm working on is slowly replacing an existing system and one of the worst smells we've come across is the mixing of Reporting and Data Entry functions in an application.
Firstly the Searching/Reporting is time consuming (5-60secs+) full table scans on their order tables including filtering on obscure low cardinality columns which were often derived or dependant on child table row existence...

The table in question is the primary order entry table for the business, so it has alot of contention already.

To make matters worse they are currently using SQL Server which has a proven incredibly useless locking mechanism. We have tests that prove that readers block writers when competing for the same resouces.

The old system reduced the affect of some of these limitations by using READ_UNCOMMITTED Isolation Level alot.

It appears as though they tried not to think about any sort of locking, pessimistic or optimistic.

It's been a slog to get business to give up what they already have been given, but Greg is very persuasive.

Some prior work had already come across the Reporting issues so there was already a Reporting Server that has data upto a week out of date.

All reporting aspects of the story could be moved over to the reporting service. We agreed on a date range that our system would search over and for searches prior to that could be performed on the reporting server.

That was most of the problem solved, the other issues are why our project started in the first place.

Tweet This Post