There are so many variables, I don't know how you could qualify a "good" ratio of Developers to DBAs. DBA can mean a lot of different things. If you have a few small (<10GB) databases in a small shop with not much change happening, then a decent "jack of all trades" can usually cover the jobs of DBA and developer as well as server admin.

I think you have to base the number of DBAs on the number of servers/databases/sizes that you have. Once you get past 100GB of data in the databases, you really need a dedicated DBA, unless you have 1 large database that you don't change much. Of course, if you have a dozen servers with a dozen 1-2GB databases on them, that requires more time to manage. I think that SQL Server out-of-the-box works great until your databases grow to over 10GB. That seems to be a good general benchmark of when you start seeing performance issues that you just can't keep throwing hardware at to make it work better.

Also, if you are in an industry with compliance issues, you might be at risk if your "DBA" is busy tweaking style-sheets. A lot of people call themselves "DBAs", right up until that dusty box in the corner that the vendor set up starts having issues. As the company grows, so does the databases. A good developer can usually put together a fairly good data model and create some useful indexes, but, eventually, you will have performance issues that will not heal themselves. When was the last time you tried to restore a backup, just to be sure it's working correctly? How long since you last refreshed your dev environment? What about upgrades? What about High Availability? What about security? All that data is kind of useless unless you create some good reports and/or dashboards that you can actually make some business decisions about. Considering a data warehouse?

Of course, then, as the IS department grows, is everyone following the same master plan, if there is one? From what I've seen, you don't always get instant "synergy" when you start adding more cooks to the kitchen. Our IS group of 9 people gets a lot more done than the last group of 60-70 could do because we don't bury ourselves in "process", we don't have anyone on the team that wants to stand in the way of progress because they are scared of what is unknown, and we don't have anyone doing the over-promise/under-deliver stuff. It's nice to be the one-man IS/IT department, but you have to know your own limitations. I think most of us in IS/IT have a bad combination of megalomania and poor estimating skills. It's easy to get cocky when you create an index that improves performance by 1000%, but then you might have another emotion altogether when someone asks you to recover some lost data!