August 17, 2009 at 9:38 pm
Comments posted to this topic are about the item DBA: Mentor vs. Protector
Regards,
Matt
August 17, 2009 at 10:20 pm
In the dev environment I would say mentoring is important with an eye towards security. In the production environment data protector is the most important..
CEWII
August 17, 2009 at 11:06 pm
Certainly in the production environment, the buck stops with the DBA for any bad structures. Because of this the DBA must be protector on the Production, QA and Test environments.
IMHO the average programmer does not understand database performance issues especially in the case of large databases making them dangerous if left unchecked. I favour the programmer having his own database to code against etc, but there sghould also be a common pre-test build environment and corresponding database. Any database scripts should be under code control just like programs. In this context, the DBA is the programmer.
Sorry Matt, but in my experience ex Access programmers are the most dangerous when it comes to [not] understanding the performance issues arising from 100+GB OLTP databases.
August 18, 2009 at 1:18 am
To learn, one has to try something new. To try something new means risking failure. If you're not making a few mistakes, you're not trying to learn. In my opinion, one of the best ways to help someone onward is to give them just a little more responsibility than they can handle.
Now, mistakes cannot realistically be tolerated in a production environment, hence the need for the dev, test, pre-prod and sandpit environments. However, what's the use in creating somewhere for developers to develop (together with the bugs they'll encounter along the way) and then locking it down so tight as to all but stifle the development?
As we've discussed on previous threads, I believe security is only in part a technical issue, the greater part being the human dimension. If the DBAs and developers in a team work at their relationship rather than relying on technical safeguards and barriers, the understanding that grows between them can be reflected in wider (monitored) freedom within the volatile development environments. And, because this scenario involves DBA and developer working together, any code that has to be promoted to live has already become familiar to everyone involved.
Yes, I believe there's a happy medium, but I don't believe it to be a compromise. Rather, I believe it to be the best of both worlds.
Semper in excretia, suus solum profundum variat
August 18, 2009 at 1:37 am
Depends on the organisation, The production environments have always had been the DBA pregorative and closely guarded, being a developer as well as a dba for a number of years i can see both sides of the argument. The trouble is, is that not all developers are alike or even have the same skills/knowledge/attitude.
Some of the organisations I have worked for in the past, the dev boxes have literally been given over to the developers who have done what they want to them, having full sysadmin rights. I have mentored in the past, junior dbas and developers who wanted to learn. But never within any other environment then development. With all the best intentions, a production box is not a toy or a learning curve for inexperienced people. I personally think that mentoring is down to the individual and based on his/her experiences. if you have developers who constantly screw up. it does influence your decision in what rights you give them. No developer should have access to a production box, and I believe that strongly. as a dba you have sole responsibility for production and your job rests on that. I also believe that developers should be able to do what they need to, in a development environment without restriction and if they need help they can ask a dba for it.]
So basically, a protector of the production environment and a mentor for the development environment. A good dba can be both. 😀
~Silverfox~
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
August 18, 2009 at 6:00 am
Organizations need both. No, we don't want developers experimenting on a production server, but they do need a sandbox where they can try whatever comes to mind. Whether that's a "real" dev server or a locally installed instance, they need that freedom.
In my view the 'lock it down' mentality often comes from a desire to avoid problems than a true desire for security. Very common for PC support people to do the same - don't let users change things like screen resolution because it might break something!
Security is serious stuff and shouldn't be dealt with lightly. But at every step we must also make sure our customers (the ones that pay and the ones that develop) can get to the data they need.
August 18, 2009 at 6:49 am
Developers do need a sandbox, but they also need to maintain control of their dev environments. Too often they don't know what they changed to get something working, or they don't "undo" a previous change somewhere before making another one. That results in not an experimental system, but an unknown one.
I think Devs should have a person VM for really new changes and experiments, but either they or a DBA needs to maintain some control over changes in dev. Not to be too much of a protector or "lock it down" person, but to ensure those changes can be replicated later.
August 18, 2009 at 6:55 am
I think a certain amount of freedom for developers in the test area is fine. Creating indexes, show plans, etc. are all part of giving them tools to help me help them get better faster code. But when it comes to creating tables, I'd lock that down. Most developers I've dealt with just don't understand how to normalize a database or (more likely) just don't care because their 3 rows of test data returned just fine while they were developing and once we test with load, the dba can make it better.
The problem is (at least here) once a developer writes code against their non normalized table that doesn't bother to follow naming conventions, that's it. They never want to have to revisit and change that code again. I just saw a new production table created while I was on vacation. It has 20 columns, 1 identity and the rest are varchar(max). Nice.
August 18, 2009 at 7:11 am
I favor a completely open playground, a slightly locked down dev box, and totally locked test, QA, and production boxes.
The playground is where you can try just anything at all. Should be a VM these days, with a "last good image" available to rebuild from in the case of "oops!" type situations. Probably need one per dev, but conflicting tests might be worthwhile too.
The playground is for proof-of-concept and hair-brained ideas.
Dev should be under source control, and should only have changes made that someone thinks will actually one day make it into production. But devs should have access to viewing execution plans, index use, et al, definitely, so they can refine code as they go.
Test and beyond should be locked down and shouldn't have anything on them that hasn't been through code review. They should replicate production as closesly as possible so that any effects can be tested in an environment that is as real as it can get. Thus, if production is to be locked down, then test should be too. Test and pre-release should have maintenance plans running on them, and backups.
That kind of set up makes sense to me.
As far as the relationship between devs and DBAs, I think it should be close. The DBAs should advise the devs on how to improve code and devs should advise DBAs on what to expect from upcoming solutions.
- 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
August 18, 2009 at 7:15 am
Excellent points Matt!
I have to agree with most of the comments above. DBAs lock down development environments when someone makes a mistake that takes the development server to its knees. That's going to happen if people are allowed to experiment.
Folks have to be free to fail if they're free to succeed. It's part of the equation - the equal and opposite reaction, the give and take, upside and downside. I believe the benefits outweight the costs, but I know from experience there's a time and place to tinker and learn, and a time and place where that should not be permitted.
I like Steve's idea of virtual machines a lot.
I also advocate training application and web developers in a database development methodology. Teach them how to fish; start with how to bait a hook (write re-executable T-SQL) and prepare fish (use transactions when deleting / updating).
There's a fine line between beng a gatekeeper and a roadblock. Any given situation can appear to be either, depending on which seat you occupy.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
August 18, 2009 at 7:22 am
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.
August 18, 2009 at 7:51 am
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.
August 18, 2009 at 7:57 am
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 😛
August 18, 2009 at 8:47 am
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?
August 18, 2009 at 9:00 am
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
Viewing 15 posts - 1 through 15 (of 44 total)
You must be logged in to reply to this topic. Login to reply