• Premature optimisation is the process of making design decisions or modifications based on assumed performance improvement without testing, benchmarking and verifying the change.

    "Foreign keys are slow so I won't create them" is in fact an example of premature optimisation. (unless someone has sat down, done the measurements and found that in this particular case the foreign keys are unacceptably slow)

    "I'm denormalising for performance" is another common case of premature optimisation, someone has assumes that normalised designs are slow and denormalised without testing that assumption (at least I've never encountered a case where they did test).

    Optimising queries or tweaking data models or playing with hints or indexes without any measurements and without any idea of the results of the fiddling is premature optimisation

    Creating a good, solid, scalable design is not premature optimisation. It's doing a good #@$@# job.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass