Database superstition
Superstition has no place in database work -- or IT, for that matter
Follow @infoworldIt happens quite often that a dev will write a solution to a problem based off of some perceived potential problem. And quite often it happens to be completely unwarranted and unqualified as well.
Let's take an example of a place a friend of mine used to work. I would mention them by name, but that would just be mean at this point. So my friend was getting reports of horrible DB performance in their apps and was given the task of fixing it. In his searching, he found that the data and log files were on the same partition and the bottleneck was being created there. So he went to his boss and said, We need to split these files onto separate partitions and performance will go through the roof. To which his boss responded, I'm not going to put an untested architecture in my production environment, you'll need to test it first. Now let me say that his boss was the senior DBA, not a manager-type.
Then my friend told him (in amazement at even having to say it) that it was industry-standard practice, and that it didn't need to be tested. To which the senior DBA replied, But anything could happen, so we just can't risk it. WHAT?!?!?
OK, first of all, what is "anything"? What are you specifically afraid of? Because "anything" can't happen. For instance, your DB files can't just convert themselves to Oracle files or to Excel files during the move and all of a sudden become incompatible with SQL Server. The files aren't going to suddenly start deleting records or dropping tables. So clearly "anything" can't happen. So what is it you're afraid of? Are you afraid they'll move incorrectly and become corrupt? In that case, how about I copy them and keep the originals until we've verified that they're good in the new location? Would that work for you? No? Why not? Because anything could still happen. No, it can't. Give me some more specific scenarios you're afraid of and we'll take steps to prevent them, etc.
Another time at the same gig, my friend implemented the perfect XML solution to one of their biggest problems. It was elegant, fast, and cool. It hit the trifecta. However, he, of course, had to call the XML namespace on microsoft.com, and his boss kicked the solution back because calling an external source like that wasn't safe. Anything could happen with a hacker wanting to break-in, and he just couldn't take that chance. Three weeks later, my friend turned in his notice.
Again though, what is "anything"? Because anything couldn't happen. And it's just stupid to deny an excellent solution just because it has a reference to an external source for a namespace.
