Oracle SQL Developer Data Modeler supports the one-gal design boutique shoppe and the mega-huge development team.
It HAS a file-based repository (Subversion aka SVN.)
You don’t have to use it, but you should.
You can optionally store your designs and data dictionaries in a database for reporting purposes. I strongly recommend you do so.
If you do add your design to a repository, once you save it, and BEFORE you COMMIT your changes to the repository, you can view your Outgoing Changes.
4 changes, 3 objects are touched AND the diagram has changed.
That’s great to know. But what EXACTLY are the pending changes?
Right Click!
Now you can see what’s what.
Let’s zoom in a bit:
Ok, that’s a big change. Two big changes actually.
What’s up with that diagram though?
Ah, so the objects have MOVED around. Yes, that’s a change.
What if there’s a conflict?
You can merge some or all changes. You can walk over to your co-worker and hash it out. You could branch YOUR changes to a new design and try to work it out later (not recommended, probably.)
Heli’s new data modeling book has an entire chapter on how to deal with versioning and resolving design conflicts.
And Incoming Changes?
Same difference, just stuff that’s about to happen to your design if you get the latest version off of the repository.
Heli and I did a cool session at Open World last year where we went back and forth to demonstrate this workflow. It’s really not that complicated. The hard part is doing actual design work and working out conflicts with design decisions, not with the design tool.