The bigger the organization, the more likely you'll do the nice pretty diagrams. The other correlation is that if you work for a consulting company, you're also a lot more likely to do pretty pictures. I've done lots of ERDs, some of them with 100+ tables. If you're working with any of the major commercial databases, you'll want to take advantage of foreign keys. It's actually easier to do this with a design tool since the better ones will migrate keys for you and take care of other bookkeeping stuff. You then generate the DDL and you're done.
The big organizations tend to be big on structured process (though not always). Structured process means documenting the heck out of everything which means lots of pretty pictures. Consulting companies like to show that they're working for that $150 - 300 /hr you're paying them, so they try to bury you in paper. Pretty pictures take up lots of paper.
DFDs are nice, but aren't exactly mainstream these days. UML is the standard in the object oriented world. Use case diagrams, class diagrams, activity diagrams, etc. Again, the larger (and/or consulting) groups will tend to do this stuff. It helps if the project is complex enough to merit doing the diagram work. For small non-complex projects, doing the diagrams can be more work than the actual work.
Potential employers of a certain type love to see familiarity with the various diagramming standards on resumes. That alone is reason enough to suffer through it.
Linear Mode
