• Tutorial to Create a Power BI Report Using PostgreSQL
• How monitoring tools can help you excel at your job
• Build Your Own SQL Server Central Monitoring Solution with PowerShell
• From the SQL Server Central Blogs - Getting Started Speaking – #NewStarNovember
• From the SQL Server Central Blogs - SQL Homework – July 2022 – Getting ready for the next time you have to look for a job.

• The VALUES Limit

Daily Coping Tip

Get outside and observe the changes in nature around you

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

What's the Edge Case?

Quite a few of the bugs we see in production systems come from data that isn't handled well. Perhaps the developer never considered this data, or another bug lets data into a system that should never be recorded. These are often NULL values, but they could be other data values that are far out of the ordinary.

Where do we draw the line for edge cases? Is it anything that doesn't fit 95% of the data range? I see this number used in many fields, often manufacturing and other "physical endeavors". Is it the 80% rule, where we ensure 80% of data cases are covered, but 20% represent special handling?

It's an interesting thought because drawing this line helps us decide what level of data we need in our dev and test environments. We need enough data to represent what exists in production, but not much more. The less data we have, the faster everything moves, with much less friction in setting up, resetting, and moving these databases around.

However, the more bugs that slip through, the more we might need to ensure that we add more data to our development environments to mimic what is in production. Often we have used copies of production data, but there are plenty of issues with this. First, we often have less security in non-production environments and no shortage of data breaches comes from these systems. Therefore we might need to apply masking/obfuscation/pseudomization to values. Second, production databases are growing larger, often over 1 TB. While storage and bandwidth are cheap, they aren't free, and moving around 1 TB of data regularly, or even restoring it, can present resource challenges.

My preference is a representative set of data from production, masked and without PII, along with some randomness that might catch edge cases before we deploy changes to production. With that in mind, what's the edge case? I think I'd lean towards the 95% value, but ready to raise that higher if we discovered many bugs.

How many are many bugs? I might apply the same standard. If more than 5% of bugs filed are data issues, we need better dev/test data.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums