Software Engineers and DBAs

Question

What are main difference between these twos? Up to which extend, a SE need to know about databases? Should they(SE) know the details of underlying db?

Where is the border between those two?

Answer 1

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.

Answer 2

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:

• data modeling
• requirements for the data storage (record structure, size of tables, number of inserts/deletes/updates per second, how quickly processes need to complete, etc)
• requirements for disaster recovery / continuity of operations (needs to be back up within (x) hours, can't have longer than an (y) hour maintenance window each (month) )
• implementation of the storage (selection of the database software, selection of the physical storage, how the tables are spread out on the storage, etc.)
• implementation of the backup plan

And then the maintenance type tasks:

• tuning the database
• tuning the queries
• debugging when things go wrong
• overseeing & verifying the backups
• applying software updates

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.

Answer 3

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