September 12, 2002 at 11:45 am
> Ask any DBA worth their salt and they'll tell you that programmers don't understand databases...
Generally, probably true. Absolutely true? No. (BTW, the way your statement is phrased sort of "poisons the well".... The opinion of any DBA who disagrees is automatically suspect, because obviously he isn't 'worth his salt'.) I've known many fine programmers who understand database very well. Some programmers do overuse cursors. Some others could show many DBAs a lot.
September 12, 2002 at 12:52 pm
Lee,
As a programmer and a DBA let me acknowledge that there are some programmers that do know their way around a database from both a design and administrative viewpoint. The issue is that there are a much greater number who think that they do but don't. The basic difference is that a DBA will program the objects from a set-based approach whereas the usual application programmer will get a recordset and loop through the records one at a time.
My statement that most (not all) programmers don't really understand databases is true, IMO. They don't understand data normalization or when or why to denormalize. They don't know where to apply indexes or which type of index to apply. They couldn't optimize a query if their life depended on it. They wouldn't know how to minimize or prevent locking conflicts. They don't even consider these topics in their design. The issue is not that they don't know the answers; it's that they don't know which questions to ask.
Some do. These people are rare and valuable. Hopefully, their employers or clients realize this.
As for the DBA's... We are a consulting shop so we see a variety of third party or home grown packages. The general level of adherance to generally accepted best practices is appalling. From the physical implementation foisted on the end user to the operating inefficiencies to outright security mismanagement, these products expose the client to a host of woes. This is, IMO, the norm rather than the exception. These are database applications from companies that should know their way around a database. Either they don't have a DBA or the DBA they have "ain't worth his salt".
Steve Hendricks
MCSD, MCDBA
AFS Consulting Group
(949) 588-9800 x15
Steve Hendricks
MCSD, MCDBA
Data Matrix
shendricks@afsconsulting.com
(949) 588-9800 x15
September 13, 2002 at 2:51 am
In an attempt to get (sort of) back on topic...
One thing is for sure, more people will implement (well or otherwise) SQL Server. Good for us who have chosen to specialise. The fact that more systems will be implemented poorly shouldn't impact on demand for our skills, because we'll hopefully be invited to fix the poorly implemented systems.
Or diversify. Not my style though.
September 13, 2002 at 4:41 am
I would disagree as well. I am both a DBA and a Programmer (Basic(VB and regular), Java, C(++), html, SQL, and Crystal Syntax). And if you look at the things I have accomplished, I can safely say I more than understand databases design and their inner workings. However, I will agree depending on the syntax the problem is can a DBA control what syntax is used with Yukon. The major issue I see is if the system is open to any language choice then you will get VBScripters, Java Scipters, Cobol Scripter, Perl Scripters C# Scripters, TSQL scripters, etc, etc, etc. Now if the DBA only understand s say VB and TSQL then a lot of foul code can be written he will not undertsand to stop and prevent. This is just going to make te DBAs life h&!! to deal with and I am not for it. However maybe MS will understand why so many companies may wait a while before they dive into a prodution Yukon SQL server when finally rolls. Heck I did the .NET beta and gotta say that even thou I can work quite well in it, it may be at least 2 SPs before our company as a whole considers it.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
September 16, 2002 at 10:42 am
Thanks for the comments and interesting stories. Hopefully things will turn around all over soon.
As far as DBA v Developer/Programmer. In my experience, most developers are ignorant about good database practices. They just haven't been shown or have stumbled through. Note that I say most.
I know some fantastic developers who understand databases, but it's not the norm. Most developers tend to think in procedural logic, whereas in SQL, it helps to use set theory to solve problems. Not that difficult to learn, but I think it is like pointers. Some people grasp the concept immediately, some never get it. Others take time.
.NET is important (not critical) for DBAs. SQL Server will get NET enabled at some point and it would be prudent to be prepared. Also Exchange will start to use the SQL Engine (not next version, but the one after that), so you'll likely be helping the mail people at some point as well.
I will admit I'm kind of scared of getting some VB.NET stored procedures. Shudder, cringe. I think some things are better left separated.
Steve Jones
September 16, 2002 at 10:52 am
quote:
Generally, probably true. Absolutely true? No
Finally a realist. I have been in this industry for a relatively short time (1986)working for numerous corporations in both permanent and contractual positions. During this time I have met and worked with many varied levels of skills and disciplines. Me, I'm a programmer and proud of it. Not a DBA, although I very much appreciate what they bring to the table. However, being a programmer does not stop me from performing many of the DBA tasks - knowledgeably - Any muppet can read BOL.
When I first started I always assumed DBA stood for "Does Bugger All". This was certainly the case for the guys responsible for the DL/1 database at one company. However, over the years I have mellowed and come to the realisation that we all have different skills, some of which overlap.
Just like Sets and Venn Diagrams!
With this realisation, I also now believe DBA's and programmers would be better off working together rather than competing. Surely were all supposed to be creating systems and applications that go to aid someone or something. That someone does not give a damn about the differences between the disciplines of the people used to generate the application or the system. So why bicker?
Surely during this down-turn in the economy we would all be better off joining forces and sharing skills so that we all become more vital and adaptable for the organisation in which we earn a crust.
If the powers that be then decide to make one person redundant, at least that person will have gained several more skills with which to sell their services elsewhere. Had they just taken the narrow minded view of DBA's stick with DBA's and Programmers to Programmers they immediately halve their horizon.
By working together as a team, you can gain very valuable skills for the future.
And you never know, you may even end up liking each other!
Lets all stop trying to determine whose the cleverest, a DBA or a Programmer. The fact is I could scare the technical crap out of a DBA with some of my logic processes just as I'm sure they could me, with theirs.
Lets just appreciate each other and instead fight the prats that escaped to management because they were technically useless! You know who you are!!!!!!
September 16, 2002 at 11:00 am
Thanks, swjs, for a most entertaining rant! (I mean that in the nicest possible way.) I have never understood this imaginary brick wall that is supposed to separate programmers from DBAs, glad that others feel the same way. Good day to you, and may neither of us ever become a 'prat' (don't know what one is, but it sure sounds ignominious).
September 17, 2002 at 6:03 am
I think Steve's got to the centre of the problem, in that the two skills require different ways of thinking, just like speaking French or German. And just because you're good at one doesn't make you good at the other. Nor does it necessarily make you bad either. I've not been a full time developer for seven years now, but I can still remember how steep the learning curve was when I first started getting into the non-trivial activities that mark a proper DBA. Conversely, I also now spend much of my daily 2hr commute coding VB apps on my laptop that do things that Microsoft left out of SQL Server. And I know that I can still teach *some* developers a thing or two about coding, just as I can most definitely learn from others, but I view that as a good thing in that I can share experiences that make myself and (hopefully) others better. Can't beat education for seeing someone else's point of view. Conversely, I've also worked with a couple of DBAs in recent years from whom I've learnt alot about SQL Server internals, which I appreciate hugely.
Where much of the friction appears is when coders try to pass themselves off as DBAs when applying for jobs, not realising how much there is to providing a completely different skill. Right now I'm reading a CV from a guy who's obviously an out-and-out programmer, yes he's applying for a production DBA role. Maybe the mindset of the DBA makes for a wider (IT) world view, where more has to be taken into consideration. I know I now think way more about the consequences of what I'm about to do as a DBA than I did when I was a programmer. But maybe that's just age and experience.
The other thing I find is that managers who have never worked as a coder, DBA or technician, don't take small issues like licensing, server sizing, security, configuration etc into account when putting together a development project and budget. The world seems to be getting more densely populated with these people (read:prats).
I've lost count of the number of times a manager has turned up at my side asking for a server that is scheduled according to 'them' to go into production next week, and you've only just been told about it. I'm always very wary of IT "management" who've never worked in the support and development side of IT, as they have zero appreciation of the issues or problems you can face when they don't engage their brains. And then they wonder why everything goes pear shaped and their staff walk out the door. These people are the real danger, not just to IT, but more particularly to the businesses who simultaneously employ them on vastly inflated salaries, and are directly threatened by their incompetence, spinelessness and lack of experience.
But maybe that's a separate thread...
BTW Lee, a prat is a fairly polite, ignominious, Anglo-Saxon expression meaning twit, berk, fool, idiot etc... Good for use in front of your grandmother if you don't want to offend, but I'd not call your boss one, even if (s)he is.
Edited by - jonreade on 09/17/2002 06:24:44 AM
Jon
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply