Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


DBA: Mentor vs. Protector


DBA: Mentor vs. Protector

Author
Message
stephen.lear
stephen.lear
Grasshopper
Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)

Group: General Forum Members
Points: 16 Visits: 38
Your comment concerning Access is a bit unfair. Everyone starts somewhere. Just because a person started badly you can't judge the rest of their career on it.

Personally, I have an understanding with my Managing Director: If MS Access is involved, I can be scathing, sarcastic, but not cruel.
Joe Johnson-482549
Joe Johnson-482549
SSC Veteran
SSC Veteran (206 reputation)SSC Veteran (206 reputation)SSC Veteran (206 reputation)SSC Veteran (206 reputation)SSC Veteran (206 reputation)SSC Veteran (206 reputation)SSC Veteran (206 reputation)SSC Veteran (206 reputation)

Group: General Forum Members
Points: 206 Visits: 262
I agree with GSquared -- open and shared sandbox, a little tighter security on the dev and QA and production are locked down. I've been in situations where dev was so locked down, it took a team and a lot of time to get simple enhancements working. I've also been where QA and production were not locked down. We had a lot more problems with the second, but the first was almost as bad because we couldn't accomplish anything on time or with limited resources.

It was even worse when I contracted and worked at some places where they weren't willing to pay for a differentiated landscape. Of course, VM's weren't around at that time and they make a world of difference. I use VM's for my development platform and for my sandbox with copies of them that I can swap out (and do) on a regular basis.

Regards,
J.
lance.benson
lance.benson
Grasshopper
Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)Grasshopper (13 reputation)

Group: General Forum Members
Points: 13 Visits: 20890
stephen.lear (8/18/2009)
Your comment concerning Access is a bit unfair. Everyone starts somewhere. Just because a person started badly you can't judge the rest of their career on it.

Personally, I have an understanding with my Managing Director: If MS Access is involved, I can be scathing, sarcastic, but not cruel.


As an Access developer, I'm happy to say Access allowed me to discover the world of relational databases and data modeling (which get me some very strange looks at the office). I think many Access developers are at least somewhat informed of the limitations of Access. But as I continue to outgrow Access, both by skill-set and business need, I have a very similar understanding with my manager...I am scathing, sarcastic, and somewhat cruel...regarding their lack of budget for a SQL server. I dream of thousands of access databases disappearing once that SQL server is up and running...but I'm sure it's only a dream...

Of course, I had our top Access developer once tell me that relational integrity is nothing more than an annoyance and should never be used. So I suppose that Access does create some terrible habits :-P
edill
edill
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1582 Visits: 23
First of all, I am more of a developer than a DBA and while I understand and can work with SQL Server fairly well, I would never claim to have the level of skills that a full DBA would have.

As a developer, I require two things before devopement can starte:

1) A database schema
2) Test data

Since I've never worked on a new database that was created with everything needed by the project, I would also expect to have the ability to create tables, an index or two, stored procedures, and to grant access to these objects as needed in a DEV database.

I have leaned over the years to help the DBA keep Production and Test up to date by keeping detailed notes on each and every change I make to the DEV database.

I also do my best to instill this practice into the other developers wherever I work.

What more would the DBA's here like their developers to do?
GSquared
GSquared
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16233 Visits: 9729
stephen.lear (8/18/2009)
Your comment concerning Access is a bit unfair. Everyone starts somewhere. Just because a person started badly you can't judge the rest of their career on it.

Personally, I have an understanding with my Managing Director: If MS Access is involved, I can be scathing, sarcastic, but not cruel.


I have to agree. I started with Access, and I've moved up to some highly transactional SQL databases.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Silverfox
Silverfox
SSCrazy
SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)SSCrazy (2.8K reputation)

Group: General Forum Members
Points: 2834 Visits: 1161
edill (8/18/2009)
First of all, I am more of a developer than a DBA and while I understand and can work with SQL Server fairly well, I would never claim to have the level of skills that a full DBA would have.

What more would the DBA's here like their developers to do?



whoah, How long have you got, maybe If i can find a developer who can send me a script that actually parses, that would be great improvement, or even if they bother to test it before they give it to me, that would be fantastic.

re-runable scripts, that is the biggest bug bear that i have, regarding scripts from developers. I should be able to run a script multiple times, repeatly if i want to, without harming either the schema or data. so the script must have a use [database], object creation checks and be able to undo data changes. that isnt much to ask, and I do appreciate it :-D


Anything else and I think I am pushing my luck some what :-P

--------------------------------------------------------------------------------------
Recommended Articles on How to help us help you and
solve commonly asked questions

Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden
Managing Transaction Logs by Gail Shaw
How to post Performance problems by Gail Shaw
Help, my database is corrupt. Now what? by Gail Shaw
blandry
blandry
Old Hand
Old Hand (369 reputation)Old Hand (369 reputation)Old Hand (369 reputation)Old Hand (369 reputation)Old Hand (369 reputation)Old Hand (369 reputation)Old Hand (369 reputation)Old Hand (369 reputation)

Group: General Forum Members
Points: 369 Visits: 723
Nice post Matt!

I am an executive who does not tolerate any "keys to the kingdom" funny business. In my career I have twice fired employees (DBAs) who played this game. Job security is not gained by keeping other coworkers from what they need to do their jobs, and I personally will not tolerate this kind of thing, and find it one of the most distasteful habits any worker can develop. So I would advise you first and foremost to ascertain whether or not this DBA is merely protecting his "empire", or truly worried about something it is not his area to be worrying about.

If this is something he is truly worried about, and his motives (though skewed) are honest, then you need to talk to your manager. I once again find myself astonished to have to state the obvious but - businesses run by all workers working together in the most cohesive and supportive manner. If you are not getting this, then the business has a problem and a manager should address that because the business is what feeds all employees.

All this said, the term "Administrator" in DBA does not mean that person administrates people, coworkers, employees in general or the public. They administer data. This DBA should be working FOR you, supporting your efforts, and assisting you where ever needed. Simply put, DBA's Serve - THEY DO NOT RULE. That is what executives and managers do. The DBA role can lead a person to a presumed arrogance that is beyond the business ethos and that is unacceptable!

I would suggest that if you are not getting support, full support from this DBA, you need to inform a manager. You should NEVER work anywhere where the "team" is really nothing more than a collection of small kingdoms with people pretending to be important because they withhold, obfuscate, and 'control' data - something you must have to do your job.

If you worked for me and came to my office and informed me of what I am gleaning from your post, I would be meeting with the DBA today - and by the end of that meeting he would be supporting you and all coworkers, or looking for a new job.

There's no such thing as dumb questions, only poorly thought-out answers...
rboggess
rboggess
SSC Rookie
SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)

Group: General Forum Members
Points: 43 Visits: 88
Clearly, I'm missing something. Either that, or I'm horribly spoilt. Just for clarification, we're talking about playing around on a development computer. A computer, disk (or disk array), an entire RDBMS that's isolated from the primary production system, and preloaded with simulation data, right?

What protection? There shouldn't be any real data in there. I come from an environment where for the past 15 years, the computer names of some computers was classified as top secrete. Likewise, the data in them, was sometimes Eyes Only. Creating bogus data took some consideration and review, but it's mostly a one-shot thing.

What are you protecting? Doesn't the DBA/System Admin have a ghosted (or eqivalent) image? I mean, hey, crash it, wipe it out -- hell, beat it with a stick, they just wipe it clean and start over.

Clearly, I'm missing something. I'm shocked that this is even debatable! Put me down for the developer has free reign on a development box. Especially developers that know little to nothing about database management, development, etc.
joshusch
joshusch
SSC Veteran
SSC Veteran (292 reputation)SSC Veteran (292 reputation)SSC Veteran (292 reputation)SSC Veteran (292 reputation)SSC Veteran (292 reputation)SSC Veteran (292 reputation)SSC Veteran (292 reputation)SSC Veteran (292 reputation)

Group: General Forum Members
Points: 292 Visits: 49
First, let me state that I'm a developer, not a DBA, so obviously I'm biased :-P

In the company I work for, DBA responsibilities are really spread out all over the place. Developers actually build pretty much all new database objects (tables, procs, etc etc), but the systems are reviewed by the people that will be supporting the code as well as "real" DBAs (but not in all cases if I'm not mistaken). In my opinion, we wouldn't be able to do our jobs as developers if we didn't have this freedom. Now I'm not talking about the QA, Staging, Production environment, strictly the true TEST environments.

I frequently talk to some friends in a sister company that have what's considered the DBA's dream. ALL database servers are completely locked down. If a developer needs a new database object, they request it and might see it days later if they're lucky, not because any PERSON is slow, but there's a lot of red-tape (prioritization, etc). This is EXTREMELY frustrating for the developer who has to hurry up and wait. I should mention that developers are locked out of more than just dev database servers. ALL dev servers are off limits. Now I undestand they're finally allowing the devs to us VMs at least, but in my opinion, although that protects the precious dev servers, it simply makes what the non-devs would consider the dev servers simply an extra, non-dev layer of servers between the REAL dev (the VMs) and production, and therefore completely unnecessary (expensive and completely wasteful to maintain).

I suppose the devs in my company probably have a lot more database background than the 'average' or 'pure' developer. Shoot, I read and occassionally post to this site afterall. To sum up my feelings on this topic, I favor letting devs take a stab at creating DB objects and guiding them when they do something horrid (and we do all the time). Like others have said, we won't learn anything unless we try it ourselves. And I know every project is different, meaning there is no 'right' answer. But for that reason alone, I believe that the always-devs-locked-out-of-dev-environments approach is wrong at least some of the time (if not the majority of the time).



MVDBA
MVDBA
SSCrazy
SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)SSCrazy (2.5K reputation)

Group: General Forum Members
Points: 2533 Visits: 860
with regards to locked down environements and open vs closed environemtns, we're trialling the new Policy feature in SQL 2008 so that all dev machines and databases meet a minimum acceptable standard, and that they are configured in the same way that Live environments are.

This includes Collation, Ansi Settings, Compatibility mode etc etc

a weekly inspection of this data gives us a heads up on any potential dev issues from misconfiguration, while allowing the developers flexibility.

MVDBA
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search