Ten Worst Things to do In a Database – Day 2
Yesterday I started a series entitled "Ten Worst Things to do in a Database". My list was too big…so we’re going to have a vote this Thursday and Friday. I’ll have a question setup on Facebook this Thursday so you can vote for your top 3 worst practices out of our rapidly growing list. In the mean time, you can submit database practices that you feel are "THE WORST". We’ll add them to the list daily, and then voting starts on Thursday. Send your additions to me at facebook (there is a place to write on the wall already there…just add your items), twitter, or btaylor@sswug.org.
Well I’m certainly glad I opened this discussion up to our community. Already there are a lot of comments with areas I completely neglected. To add to our already existing list we have some great areas of concern from our readers.
Jonathan:
I think you are light on the operation side. My suggestions relate to large production databases:-
Not have a documented change management process with:-
peer review for major changes
approval by one up or peer review group
detailed step by step backout/rollback procedure
Defined change window with backout/rollback implemented if change window is breached.
Not have a user group (mail or other message delivery) established for communication.
Michael:
How could you have left out "Shrinking a database"? (Or scheduled shrinking of a database.)
Even though you have "1. Not have and exercise a Disaster Recovery Plan", I would include "Not having regularly tested restores.)
Michelle:
I’d like to add to number five a sub point of "documentation in a foreign language!"
Chuck:
OK, I’m guilty of at least half that stuff.
But, I have a pet peeve when I see bigint defined where it isn’t even close to being appropriate.
Terry:
Not backing up or verifying a production backup.
Ralph:
Not have any indexes (Primary or otherwise) on any of the tables.
Elana:
This is a great idea. Unfortunately, I think that 10 is not enough.
Also how about having tables that have multiple relationships? I.e., using a type field to relate one table to 10 others? so if you have tableA, which has a TypeID column. Use that TypeID to determine which other table the data in TableA is related to.
Piotr:
that’s easy – upgrading schema and rearranging the data
Well, keep the great thoughts coming. I can’t wait to see your votes, and find out what becomes our TOP (10), or should I be saying our BOTTOM (10) bad things to do in a database.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Better Application Life Cycle Management with Visual Studio Team System 2010 – Part 1
Application Lifecycle Management is an area that has quickly been evolving amongst the IT development community.
Featured White Paper(s)
Upgrading to Microsoft SQL Server 2008 R2 from Microsoft SQL Server 2008, SQL Server 2005, and SQL Server 2000
More than ever, organizations rely on data storage and analysis for business operations. Companies need the ability to deploy… (read more)
Featured Script
CheckAllTables
This stored procedure can be used to check the integrity of the data and index pages for all user tables in the particular d… (read more)