On Thu, 19 Mar 2020 21:20:38 +0000, Ahem A Rivet's Shot wrote:

> On Thu, 19 Mar 2020 20:13:33 -0000 (UTC)
> Martin Gregorie  wrote:
>
>> Most SQL performance problems, IME anyway, boil down to crap database
>> design, meaning bad or nonexistent normalisation and incorrectly placed
>> or missing indexes.
>
>  One more in a mature system - feature creep. The database was fine
> for the original spec but nobody optimised for the new queries and
> tables that got added for new features and worked fine testing the new
> features against live data - it's just a pity what it did to the
> performance under load once they got heavily used.

Yep, that would do it too, but its really just another case of same old,
same old as either the original design culprits are still there, or
they've moved on, leaving a largely undocumented system for the new guys
to sort out. Or, of course, worse still, maintenance and enhancements
have been outsourced.

My point being that its often the same mistakes being warmed over again.

I'm lucky in that, back when IDMS was a thing, I got some really good
training on its care and feeding. I largely picked up relational
databases on the job, but a surprising amount of what I learnt about IDMS
design was also relevant for RDBMS, especially the preliminaries: data
normalisation and using with Entity-Relationship diagrams to design the
schema.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05