Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««1234»»»

Organizations With No DBAs Expand / Collapse
Author
Message
Posted Friday, September 19, 2008 8:28 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:47 AM
Points: 35,347, Visits: 31,882
p.s. I also want to say that when I say "developers", I'm talking about the greater populous... there are some individual developers that I'm NOT including in my rant, but they are far and few between.

And, I forgot a very important point in my "rant" above... on that 24 hour dupe check that I rewrote to run in 15 minutes and do 50% more work? I did a little research on how long it took to develop the "bad" dupe check using "Agile" methods... it took 2 developers a week each and that didn't include acceptance testing. It only took me 20 hours from the time I started until I delivered the final UAT tested product. Not bad for an "old style DBA", huh? :P


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #572579
Posted Friday, September 19, 2008 8:47 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, June 23, 2010 7:04 AM
Points: 18, Visits: 60
Jeff Moden (9/19/2008)
p.s. I also want to say that when I say "developers", I'm talking about the greater populous... there are some individual developers that I'm NOT including in my rant, but they are far and few between.


A lot of us suck at it (playing DBA) and know it, but really aren't given much choice. Then we get defensive when someone is hired to come in and reveal that we are idiots. I used to be the manager in my group and I stepped down because I'm not good at that. I didn't want to have the project fail and get fired because I wasn't competant in that position when there was lots of work in areas that I excel in. But I can't step down as DBA; as bad as I am at it, no one else cares enough about it to do a better job (plenty of guys wanted to be manager; more power to 'em). I can do complex logic and I have written some pretty scary stored procs, but I often choose which way to do something based on how long it will take to code because I have no clue what the performance impact of different alternatives is.
Post #572601
Posted Friday, September 19, 2008 8:56 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:47 AM
Points: 35,347, Visits: 31,882
arbarnhart (9/19/2008)
Jeff Moden (9/19/2008)
p.s. I also want to say that when I say "developers", I'm talking about the greater populous... there are some individual developers that I'm NOT including in my rant, but they are far and few between.


A lot of us suck at it (playing DBA) and know it, but really aren't given much choice. Then we get defensive when someone is hired to come in and reveal that we are idiots. I used to be the manager in my group and I stepped down because I'm not good at that. I didn't want to have the project fail and get fired because I wasn't competant in that position when there was lots of work in areas that I excel in. But I can't step down as DBA; as bad as I am at it, no one else cares enough about it to do a better job (plenty of guys wanted to be manager; more power to 'em). I can do complex logic and I have written some pretty scary stored procs, but I often choose which way to do something based on how long it will take to code because I have no clue what the performance impact of different alternatives is.


I absolutely love absolute honesty... thank you for that. That's pretty much what I was talking about. Developers aren't any worse than anyone else... they just don't know what they don't know. You're well ahead of the game... you, at least, are willing to admit that you don't know about some things.

What's bad is the managers that do the same thing as you've admitted to... the part about "choose which way to do something based on how long it will take to code". Many managers really don't understand that "If you want something really bad, it normally turns out that way." :P

Thank you very much for the feedback. I value honesty/integrity probably more than anything else... if I were in a position to hire you, I would.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #572612
Posted Friday, September 19, 2008 9:24 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, October 9, 2014 1:15 PM
Points: 2,834, Visits: 3,071
Developers aren't any worse than anyone else... they just don't know what they don't know. You're well ahead of the game... you, at least, are willing to admit that you don't know about some things.


Yes at least some developers are learning because we have no choice.
However on the other hand some DBAs think they know everything and refuse to listen and learn.
What is worse? A good developer in house of a bad DBA ?????

Just hiring a DBA in house does not solve the problem, it depends on that person's skills and knowledge. If the person who interviews to hire a DBA and does not know anything about database, the chance is the company will hire a doofus as the 'wonderful' DBA.
Post #572651
Posted Friday, September 19, 2008 9:55 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Today @ 12:12 PM
Points: 1,451, Visits: 8,234

So how do fix this problem?

Should we work together to find a bunch of resources/white papers that we can present to management to should them what they're doing wrong?




Alvin Ramard
Memphis PASS Chapter

All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.
Post #572681
Posted Friday, September 19, 2008 9:56 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, August 21, 2014 1:55 PM
Points: 149, Visits: 1,027
All bashing aside, we all know that there are exceptional DBA's and Developers, just as there are horrible versions of the same.

If I had my choice, I would rather have a good Developer, one that understands the structure of the database, be a dedicated DBA than to have a bad DBA. However, what I have have commonly run into, hence the "inmates running the asylum" crack, is personnel pulling double or triple duty. They are the developer, database architect, DBA, and QC Analyst. All of the changes they are making work just fine from their perspective, all we need to do is throw more hardware at it (Vista anyone?)

Yes, I realize that something this is the necessary evil in the world of low-ball budget IT, but it dumps the ability to deal with controlled change. I find it works out a little better when there is a team to build in some checks and balances so that you are not running into the situations that Jeff Moden was talking about.

I'm sure that we have our share of horror stories. I cannot share because of confidentiality agreements, but I have had my share.


Regards,

Irish
Post #572685
Posted Friday, September 19, 2008 10:04 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, September 15, 2014 9:58 AM
Points: 15, Visits: 262
Wow, I could expound for hours on this one. And what excellent fodder for a forum of experienced DBA's who have "been there - done that". There have already been some excellent replies on this article so I won't won't relate the volumes of my own experiences on this subject - the several times when I've been called in to "rescue" the work of some wannabe DBA that has propagated a house of cards and bolted, or the work of a bevvy of programmers that have pounded-in some application with schemas and code that could only be considered server abuse. There are just a couple of points I wanted to chime in on:

Anticipate the misconceptions toward your expertise and the value of the work that you do, and evangelize SQL best practices with kid-gloves and lavish diplomacy. You must never report your findings to any member of your client company with words like, "this code is awful" or "this is just wrong", even if you speak the terrible truth. Strive to teach and bring them over to your side by shining a light not so much why their way is wrong but why your way is better. If you're as good as you say you are the reasoning you provide will become abundantly clear to them, and will smooth the way toward reception of your ideas, even if there is some cost involved (which of course, is almost always the case!). Nobody wants to hear that their work (or even the work of a former employee) was of poor quality, even if that is obviously the case and is directly attributable to the reason you're here. You must take on the role of salesman, teacher and diplomat as much as SQL guru, and with any luck the thought bubble will begin to form above their heads, "Hey, maybe it really does take a specialist to keep the back-end healthy, protected, available, agile, etc."

The other thing I wanted to say is that the reason this scenario is so common is certainly at least partly Microsoft's fault. In short, they've made it very easy to build a bad database. When you look at all the "vigilante" data storage projects out there built with Access, Excel files and build-and-forget SQL databases and the fact that many of the tools are largely GUI-based and very intuitive, this scenario is indeed, almost inevitable. Every business of every size and description needs to store and retrieve data, and they will of course want to do it in the cheapest, fastest and easiest way possible. This combined with the fact that almost every IT discipline requires at least some training in SQL Server, which means that every programmer out there will at some point hear the words, "can you build the back-end for us?" and consider him/herself perfectly capable of doing so. This is not to say that a well designed schema cannot be built by a programmer, but at some point during the life span of that solution (if it makes it to production) I can almost guarantee that it will need a good DBA to make sure it is well protected, scales properly with growth, well tuned and highly available down the road. And of course we can only hope that the original author anticipated the need to do all these things in his/her original design! ;)
Post #572690
Posted Friday, September 19, 2008 11:11 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, May 7, 2012 7:42 AM
Points: 75, Visits: 83
I personally experience this one time. I was appointed by a mid size company (50+ employees) where there was never DBA appointed in their history. I did knew this during interview but i accepted the challenge. During my first few days i figured out that there were zero security in terms of database access. Everyone from IT and few Non IT staffs were given sa password. When i did bring this concern to my manager, he did not paid much attention to my words. I also found out that the non DBAs used to work on databases and since they were totally aware of database principles and concepts, they anyhow maintained the database on server without any constraints, rules, security, etc. I was shocked and very disappointed to see this. But every time i did showed my concern no one gave much importance and i was advised that i should manage with the existing environment. After some time, i decided to note down all the points and submitted to my mgr with my concerns and then left the environment as it was before. I did my job anyhow.

In today's business there are few companies which do not understand the difference between DBA and Database Developer. Such companies many time hire DBAs for development work and the DBA end up doing something which he do not want to do all the time. Thats IT'
Post #572722
Posted Friday, September 19, 2008 11:11 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, May 7, 2012 7:42 AM
Points: 75, Visits: 83
I personally experience this one time. I was appointed by a mid size company (50+ employees) where there was never DBA appointed in their history. I did knew this during interview but i accepted the challenge. During my first few days i figured out that there were zero security in terms of database access. Everyone from IT and few Non IT staffs were given sa password. When i did bring this concern to my manager, he did not paid much attention to my words. I also found out that the non DBAs used to work on databases and since they were totally aware of database principles and concepts, they anyhow maintained the database on server without any constraints, rules, security, etc. I was shocked and very disappointed to see this. But every time i did showed my concern no one gave much importance and i was advised that i should manage with the existing environment. After some time, i decided to note down all the points and submitted to my mgr with my concerns and then left the environment as it was before. I did my job anyhow.

In today's business there are few companies which do not understand the difference between DBA and Database Developer. Such companies many time hire DBAs for development work and the DBA end up doing something which he do not want to do all the time. Thats IT'

Thanks,
Hemal Shah : DBA
Post #572724
Posted Friday, September 19, 2008 11:11 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, September 15, 2014 9:58 AM
Points: 15, Visits: 262
arbarnhart - you hit the nail on the head. When you say, "...but I often choose which way to do something based on how long it will take to code because I have no clue what the performance impact of different alternatives is." You exemplify the nature of the problem. If you have a complex query, there is a very good chance you could write it three to four different ways - and produce the exact same results. ONE of those four ways will be most efficient. I have personally re-written stored proc's that have performed anywhere from 2 to 100 times faster simply by looking at a few execution plans, understanding how the engine goes out to get the data and re-writing the code to be more efficient, make better use of stats and indexes, and before I propose any index restructuring.

Don't get me wrong - I applaud your honesty as much as RBAR and I certainly don't knock you for trying. After all, what choice did you really have? :) I just couldn't resist quoting you on this because I think that this approach to TSQL coding is very common and it furthers my point: SQL Server certainly won't raise an error if you construct code that is technically "legal" but terribly inefficient. It will dutifully try to execute it the best it can, churning away for minutes or hours if necessary until it completes or becomes victim of deadlock or connection timeout or gets killed by somebody like me! ;)
Post #572725
« Prev Topic | Next Topic »

Add to briefcase ««1234»»»

Permissions Expand / Collapse