Software starts to rot as soon as it’s written. The sooner we realise that a line of code is no longer needed, the cheaper its overall maintenance will be. Ideally during the planning phase of a feature we rule out unnecessary code. Sometimes it’s not until the code review that we realise what was just written is not needed. It’s easy to think, well the code is already written so we might as well deploy it. This might be true if the most expensive part of development is writing a line of code, but when we consider the overall cost of maintaining the code, the upfront development is probably closer to a quarter of the cost or less!
When following good database design principals, data is structured in some sort normalised form, usually Third normal form (3NF). Roughly, a table only contains columns that are all related to the primary key of the table. Usually in 3NF, a single piece of information is kept in exactly one place, which makes it easy to update and ensures consistency.
The documentation for Oracle Pattern Matching queries is a bit hard to follow, and as soon as regular expressions are mentioned things stop making sense. It’s then no surprise if you haven’t heard of, or don’t know how to use, this very powerful query feature.
In the last post: Database Performance Tuning, we saw how applying an index can greatly improve query performance. But what happens when a table already has all the possible indexes and performance is still not as good as we want?