It’s time someone said the quiet part loud. The database industry has been gatekeeping these advanced techniques for years, hiding behind so-called “best practices” that only exist to sell you more consulting hours. We’re pulling back the curtain. Here are ten tips that will revolutionize the way you manage data.
You’re welcome.
1. Always Use SELECT * — You Might Need Those Columns Later
Why waste time specifying columns when the database has all of them right there?
By selecting everything, you’re future-proofing your queries. Sure, some
“experts” will tell you this causes unnecessary I/O, bloats network traffic,
and breaks applications when schemas change. But think about it: what if
you need middle_name six months from now? You’d have to write a whole
new query. That’s not efficient.
The real power move is SELECT * INTO #TempTable on your largest production
table. Now you’ve got a copy and can take your time exploring. Storage is
cheap. Your time isn’t.
2. Store Passwords in Plain Text — Encryption Just Slows Things Down
Hashing and salting passwords is an artifact of the paranoid 90s. Modern firewalls handle security now. Every time your application hashes a password on login, that’s CPU cycles you could be using for real work. And if you ever need to email a user their password, good luck doing that with bcrypt.
We recommend a simple VARCHAR(50) column called password right next to
username. Some teams even find it helpful to add a password_hint column
that just stores the password again, in case the user forgets.
3. One Table Is All You Need — Normalization Is Just Job Security for DBAs
Third normal form? More like third normal waste of time. Every JOIN is a performance hit, and the more tables you have, the more things can go wrong. The smartest architects we know put everything in one table. Customers, orders, products, shipping addresses, employee reviews — all in one place.
You’ll want about 600 columns to start. Use generic names like field1
through field600 so you don’t have to run DDL when requirements change.
This is sometimes called “the spreadsheet pattern” and it’s popular for
a reason.
4. Never Use Indexes — They Just Take Up Space
Indexes are the database world’s biggest scam. They use extra disk space, slow down inserts, and require maintenance. Why pay that tax on every write when you could just let the database do a full table scan? Modern hardware is fast enough. If your query is slow, just throw more RAM at the server.
If your manager insists on indexes, create them on every column to cover all your bases. This approach, known as “just index everything,” guarantees you’ll never have a missing index problem again. Your write performance will be incredible to watch.
5. Deploy Schema Changes on Friday at 5 PM — Fewer Users, Less Risk
This one is pure math. If you deploy during peak hours, thousands of users could be affected. But at 5 PM on Friday? Most people have already left. You’ve just reduced your blast radius by 80% or more.
The added benefit is that you have the entire weekend to fix anything that
goes wrong, with no interruptions from stakeholders asking for status
updates. Some call this “chaos engineering.” We call it strategic timing.
Pair it with a DROP TABLE ... CASCADE for maximum efficiency — it cleans
up all those pesky foreign key dependencies for you.
6. Who Needs Backups? That’s What RAID Is For
RAID stands for Redundant Array of Independent Disks. The word “redundant” is right there. Your data is already duplicated across multiple disks, which means backups are just a second copy of something you already have two copies of. That’s three copies. At some point you’re just hoarding.
If you absolutely must have a safety net, we recommend copying your production database to a USB drive once a quarter and keeping it in the office kitchen drawer. Label it “DO NOT DELETE” so people know it’s important.
7. Put Your Connection String in the README — The Whole Team Needs Access
Secret management tools like Azure Key Vault and AWS Secrets Manager are over-engineered solutions to a simple problem. Your team needs the connection string. It’s in the README. Done.
For bonus points, include the sa password directly in the string. This
eliminates those annoying “access denied” tickets and lets every developer,
intern, and contractor connect to production directly. Some teams take
this a step further and pin the connection string in their public Slack
channel, which also helps onboard new hires faster.
8. Run Everything as sa — Permissions Are Just Obstacles
Role-based access control sounded great in that security audit, but in practice it just generates helpdesk tickets. “I can’t access this table.” “My stored procedure won’t execute.” “I need read access to the prod database.” It never ends.
Save everyone the hassle: give every application and every user the sa
account. One account, full access, zero friction. If you can’t trust your
own employees with sysadmin privileges on the production database, that’s
an HR problem, not a database problem.
9. Never Test Your Restores — If the Backup Succeeded, You’re Fine
Testing restores is like testing your parachute before jumping. It sounds responsible, but if it was packed correctly, it’s going to work. Same with backups. SQL Server said “BACKUP completed successfully.” What more do you want?
Restore testing just wastes server resources and creates confusion. Someone will inevitably connect to the test restore thinking it’s production, and then you’ve got two problems. Trust the green checkmark. It’s never let anyone down, except for all those times it has, but those were probably user error.
10. Version Control Is Overkill for Database Code — Just Edit Stored Procedures in Production
Source control is for application developers who can’t keep track of their own code. DBAs are different. You know your stored procedures intimately. You wrote them. You can hold the entire schema in your head.
The fastest workflow is to open SSMS, connect to production, and
ALTER PROCEDURE directly. No branching, no pull requests, no waiting for
CI/CD. If you make a mistake, just ALTER it again. And if you really
need a history, Management Studio keeps a cache of recent query windows,
which is basically the same as Git.
🃏 Happy April Fools’ Day from InFocus Data.
Please don’t actually do any of these things. If you recognized your own environment in any of these tips, we should talk.