My experience has been that it all comes down to proper bi-directional communications. By "proper", I mean that management drops the "I'm the boss... do it my way" attitude and actually listens to the people they hired to help them. In one job, one boss had to have something stood up "RIGHT NOW" and heard that MySQL might be the way to go. They then insisted on it. We had one person with some minor MySQL experience and they took it to the wall and that was also a part of the reason why management didn't discuss it with the rest of us because they knew that we'd recommend against it.
That person that knew a little about MySQL left the company. And, the app sucked (as did the underlying DB) with no one to fix it because they wanted it so bad, that's the way they got it.
The good part about it is the fact they we didn't even need to give management the "opportunity to fail" (not to be confused with setting them up for failure, which we did not... we didn't even know about the project). Such failures can actually be quite good because, the next time they suggest such a silly thing, maybe they'll seek out the advice of the people that are hell bent to make them look good.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair
When you put the right degree of spin on it, the number 318
is also a glyph that describes the nature of a DBAs job. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs