In other words learn to be a development DBA.

One thing I have learnt in my career is that "in the land of the blind the one eyed man is king". 

Most of my developers know how to write a simple stored procedure, but not many could write a complex set based task with convoluted business logic.  If you are in the position to make a developers problems go away then you are going to have free beer for life

Personally I think Yukon will require more DBA work. Adding all that into the RDBMS will create more and new issues, require more control of changes, and require the DBA to be more of a guardian of the system.

I think the DBA job will change because you will focus on different areas and yes, you will need to understand development to understand what the developres are trying to do to your database.

Good article.

It's amazing to me how many DBA's know how to create tables and indexes, but they have no idea how to create GOOD tables and indexes.  The first thing a DBA should learn is how to build a solid relational structure, normalized and optimized, for whatever project the development team is working on.

the "Administration Only" jobs are disappearing, especially for IT, as tasks are automated (as all repetitive work should be) and replaced by software.  This is definitely a good thing.

A solid foundation is important before branching out into other disciplines.  This is the only way you'll know when smoke is being blown up your butt...

cl

The trick is to sort the wheat from the chaff!

I've lost count of the number of technologies/technology companies that were going to be the next big thing, but after a flurry of excitement they vanished into the ether.

When you start off in the IT game both your time and your money (after taxes)are your own so keeping up isn't so much of an issue.

But as you progress through your career you find that there are 1001 things demanding your time and nappies cost a fortune so have to be careful not to waste precious time learning something with a short shelf life.

I agree with Brian and David both. I hv been a Production DBA for last 15 years. I started with Sybase and moved on to SQL Server. In the last 5 years, I hv seen job requirements changing from a pure 'System' or 'Production' DBA to a Hybrid System / Application DBA. Also, I hv seen that a lot of things which were managed traditionally by the database (such as security) now being managed by Application servers like WebLogic. Today's DBA is expected to know data modelling (OLTP as well as OLAP), CASETOOLS and also is needed to hv a good warehousing background in a lot of places.

Having said that, I must mention that though the 'fly-by-night' makeshift developer/DBAs are running a lot of installations, problems start appearing as soon as the data volume increases and a 'real' DBA needs to b hired to fix the things. That is never going to go away. More automation and features in SQL Server Yukon is only going to lead to more problems and more need for experienced DBAs!    

Here is the problem I am running into, in 2005 - the way that we have implemented SOX regulations is to segregate operational and development duties - thus, as the production DBA, I have no permission to do design work, otherwise how could they trust (and prove) that I wasn't implementing malicious code?

As one who came into DBA work as a hybrid developer/DBA, this has been immensely frustrating - and has made my job relatively boring.  I'll be definitely honing my dev skills, but unfortunately I can't really use them in my position as it stands - I'd have to cross over into our dev team, or find somewhere else not under SOX regulations....