AskTom “”Not to do” Things”

• don’t accept string literals from end users and concatenate them into your SQL (eg: DO use binds in almost all cases)
• don’t test on an empty database or a database with a small percentage of the real system. Importing statistics from a “real” database doesn’t work. You need real data volumes if you want to see what will actually happen in real life.
• don’t test with a single user, scalability issues will never make themselves apparent.
• don’t say “we’ll just whip it out and see what sticks“.
• DO think about scalability from day 1.
• DO design your system.
• DO NOT just wing it as you go along. That might sound like fun, but you’ll be working on that same system forever fixing it, patching it, trying to make it work.
• don’t take any advice from experts unless you see compelling evidence that what is being suggested actually applies to you.
• find someone willing to explain “why” – so you can increase your knowledge but also understand when something MIGHT NOT APPLY (because nothing is ever 100% true all of the time)
• don’t try to optimize by hypothesize. (it rhymes I “feel this will be slow” – nope, don’t “feel” – show it to be slow, then optimize it. Point I’m trying to make is I see people “feeling that doing ‘X’ will be slow” and trying to design a system around not doing ‘X’. Show us that ‘X’ is too slow for you (typically trying to avoid the use of a database feature because they have heard “it is slow”- eg: auditing.)