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 ««12345»»»

DBA: Mentor vs. Protector Expand / Collapse
Author
Message
Posted Tuesday, August 18, 2009 7:22 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, July 19, 2014 3:43 PM
Points: 8, Visits: 36
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.
Post #772669
Posted Tuesday, August 18, 2009 7:51 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Friday, February 21, 2014 8:14 AM
Points: 194, Visits: 255
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.
Post #772720
Posted Tuesday, August 18, 2009 7:57 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, June 26, 2013 12:07 PM
Points: 13, Visits: 20,873
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
Post #772726
Posted Tuesday, August 18, 2009 8:47 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Saturday, March 8, 2014 11:52 AM
Points: 1,582, 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?
Post #772786
Posted Tuesday, August 18, 2009 9:00 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 1:09 PM
Points: 13,872, Visits: 9,597
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
Post #772794
Posted Tuesday, August 18, 2009 9:04 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 8:58 AM
Points: 2,698, Visits: 1,131
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


Anything else and I think I am pushing my luck some what


--------------------------------------------------------------------------------------
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
Post #772800
Posted Tuesday, August 18, 2009 9:06 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, May 7, 2012 9:23 AM
Points: 304, Visits: 716
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...
Post #772804
Posted Tuesday, August 18, 2009 9:06 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, September 24, 2009 7:38 AM
Points: 33, 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.
Post #772805
Posted Tuesday, August 18, 2009 9:07 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, July 6, 2011 1:21 PM
Points: 292, Visits: 49
First, let me state that I'm a developer, not a DBA, so obviously I'm biased

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



Post #772806
Posted Tuesday, August 18, 2009 9:07 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, August 8, 2014 3:25 AM
Points: 2,283, Visits: 781
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
Post #772807
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse