I think you should go with option #3; either of the two other options will lead to heartache in my experience. You’ll end overwriting each other’s changes and other issues.
Option #3
You both set up local developments environments and you use a Subversion repository to keep things in sync. I use a free account at Unfuddle with gives you two logins and subversion repositories as well as a ticketing system and task and milestone tracking. Unfuddle works well for me but of course there are many other options, Unfuddle is just the one I know that works well for me.
As for the database, it’s very hard to manage databases in source control. What you really have to do is write scripts that rebuild your database from scratch and then version them. Ironically I’m working on exactly that for tomorrow and I asked a question here in hopes to get someone to help me but instead it looks like I’m doing it all myself so I am documenting what I’m getting done in an answer. You can read about it here:
While the above question/answer talks about initializing a new database using standard aspects you could actually do the same with existing data, it would just be more work.
Thus far in my development I’ve always been able to simply do a forklift upgrade of the database but I’m getting to the point I’ll need to manage existing data. So it looks like over time I will be building tools to export data to scripts and/or files where I can easily merge new work with current data. Sounds like you need the same. Hopefully others will come along and we can all handle a piece of this problem; as they say: “Many hands makes for light work.”
Sadly my answer is not simple regarding the database but as far as I’m aware this has always been an issue for deployment of database-related systems and scripts that you can test and submit to version control are really the only known way to handle it.