I'm wondering how many professionals on this forum actually have the freedom to choose exactly what database management system is used in their work place. Did you get stuck using a pre-existing MySQL, SQL Server, Oracle, or PostgreSQL server or did you have the option to choose what you felt was the best application for the job?

When I came on site here in 2006, we had 4 Microsoft SQL Server 2005 servers and their performance was so poor. They were installed by a developer who had little to no DBA experience but the O.S. was constantly needing reboots and I made the decision to migrate everything to PostgreSQL and it's been smooth sailing ever since.

Not trying to start a X > Y argument but I'm just trying to see how many DBA's have the flexibility to choose what they work with.

I doubt that using PostgreSQL instead of MS SQL Server was the real reason you are seeing a better performance. My guess is that the original system was poorly designed/implemented/maintained.

And to answer your question. I think most DBAs are usually stuck with whatever system they inherited.

Yes. I specified that the reason it was possibly slow was due to a non-dba (developer) installed SQL Server. I don't think using PostgreSQL had some magic performance powers over our database needs but it was a night / day difference.

I work as a consultant, so when I appear at a client's doorstep I have to make a lot of choices. How to approach this kind of issue is often the first choice that I need to make.

Some of the systems that I inherit are sufficiently complex and wedded into their environments that change is out of the question... Not for technical reasons, but because of the impact on the client that a database change would force.

Some of the new projects are in an environment that is so heavily invested ina specific technology that change is impractical. Particularly when you have truly massive database engines already running, it only makes sense to tap the existing expertise and licensing for new projects. Some shops run many instances of only one database engine, so the entire support infrastructure would need to be rebuilt to support a new engine.

Other projects are "cloud based" where the client wants to buy a "data appliance" that gets the job done, and doesn't particularly care what tools I use to make that happen. This is typically a project that is either started from the ground up, or an existing project that was a great idea but outgrew its platform... Either way I get to start fresh and picl the best tool for the job.

The short answer boils down to "it depends", which seems to be the core issue that every consultant needs to help their clients resolve.

-PatP

Slightly off topic but what exactly does a "consultant" do? When I hire you, what services do you actually render or does this vary? I've always been inquisitive of people who say "I'm an I.T. consultant" and I think to myself, what does that mean?

Do you consult clients only about SQL databases or do you have a broad spectrum.

Trying to get to the bottom of how I really work is hideously complex... It would make Machiavelli proud and Rube Goldberg more than a little queasy. What most of my clients see is that I work for the Managed Services arm of a company that builds and runs Data Centers.

My specific area of expertise at the moment is databases. DB2 and Microsoft SQL Server consume most of my time, although MySQL and Oracle get their share too.

I also do some Windows, Active Directory, Exchange, *nix, zOS, Identity Management, and other issues... I try to stay "high level" when issues stray very far from databases because we have tier 1 and tier 2 people that can handle those details more efficiently, especially on large projects.

-PatP

Thanks Pat. Very interesting for me considering I'm only 6 months deep in the SQL world.

And is what provides consultants with continuing work.