![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The more work a proposed feature claims to save you, the more work it will take to dismantle when it inevitably fails.
Computer systems offer a constant stream of improvements, features, and shiny objects to woo potential developers. Sometimes the features offered are honest improvements that will become a stable cornerstone of future development. More often than not, the sparklies are buzzword compliant dreck or some halfassed attempt to catch up with a competitor.
SQL Server's Indexed Views are one example of a feature that's simply an accident waiting to happen. Oracle implements a near identical feature called Materialized Views that actually preforms as promised. When a large, highly normalized database needed a summary view that takes minutes to return data, such a mechanism was the natural choice.
Well, if it worked. Sure, the summary comes back in seconds, but now a statement like "update table set status=1 where status=0" takes several minutes when running against the table in the view. In short, the feature is less than worthless, it's detrimental.
I ultimately isolated a very high cost join, a twenty second full table scan beast and cached the results manually with a stored procedure. I have to fire code when the underling data changes, but the data change is isolated to a process, so it doesn't get out of sync. Hmm... this would be a great place for an Indexed View... bastards.
Computer systems offer a constant stream of improvements, features, and shiny objects to woo potential developers. Sometimes the features offered are honest improvements that will become a stable cornerstone of future development. More often than not, the sparklies are buzzword compliant dreck or some halfassed attempt to catch up with a competitor.
SQL Server's Indexed Views are one example of a feature that's simply an accident waiting to happen. Oracle implements a near identical feature called Materialized Views that actually preforms as promised. When a large, highly normalized database needed a summary view that takes minutes to return data, such a mechanism was the natural choice.
Well, if it worked. Sure, the summary comes back in seconds, but now a statement like "update table set status=1 where status=0" takes several minutes when running against the table in the view. In short, the feature is less than worthless, it's detrimental.
I ultimately isolated a very high cost join, a twenty second full table scan beast and cached the results manually with a stored procedure. I have to fire code when the underling data changes, but the data change is isolated to a process, so it doesn't get out of sync. Hmm... this would be a great place for an Indexed View... bastards.