What are main differences between Database Administrators and Software Engineers? To what extent should a Software Engineer know the details of the underlying database? Where is the border between these two professions?
closed as primarily opinion-based by dezso, tblPhil, Paul White, RolandoMySQLDBA, Kin Jun 4 '14 at 18:33
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Math. I'm tempted to leave it at that, but I know without explanation, I'll be flamed, so here goes.
In my experience, DBA math is different than engineer math.
DBA math involves the impact on capacity a deployment will have. For example we as DBAs examine deploying a table by how much space per million rows it will consume on disk, what optimal queries to run against it, indexing strategies, etc.
Engineer math is going to be Big-O notation based. An engineer is going to be looking at algorithms and how to optimize them. The downstream impact (capacity planning) is a secondary concern to the efficiency of the application. However, if capacity is made a requirement upfront, then it will get the proper scrutiny.
Some of us play both roles and thus we have carved out a niche being a corporate applications dba developer.
BTW: please take this with a grain of salt because it is just my opinion.
It depends entirely on the breakdown of work at an organization, and what each person's responsible for. But they're just labels; someone titled 'software engineer' at one company might be 'programmer/analyst' at another company or even 'systems programmer', etc. There is no hard border between the two.
Where I work, the 'software engineer' tends to be the person doing both the design and the actual implementation, and we don't have anyone titled 'DBA'; The maintenance type tasks that would typically be a DBA fall back to the general 'system administrators', based on the guidance that the 'software engineer' gave them.
In what I personally think is a best case scenario, you'd break the design into multiple parts:
And then the maintenance type tasks:
For most of these, they don't have to be done by a DBA; it could be done by a software engineer, or in the case of some of the maintenance tasks, a system administrator.
If you have people in both roles, you might have them confer and collaborate on the design and tuning (what they'd call in construction 'design-build') , or if it's a rush job, you might assign the various tasks between the two. You might have other people involved, too : a 'software architect', 'data architect', an archivist, various programmers, system administrators, network administrators, security, etc.
"Software Engineers" or "DBA" are titles. Instead of asking: whom I will "SE" or "DBA"?, just ask: "should I learn C# or java or oracle or sql server to reach my goals". Have you ever seen "we need just DBA"? No :) (except some strange cases of HR). You can see: "we wanted XX, who knows and have expirience at these technologies."