Software Engineers and DBAs
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.
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.
"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."