Although "both" may be how you learn the hard way - I would disagree.
After recently completing a pretty in-depth CMS (w/ PHP & MySQL) and trying different approaches I found doing it that way lends to bad dB design or a constant reworking of both the front and back ends (which gets damn old). These are the steps I suggest (which work for me):
1. Do a breakdown of all the content on all the pages you want to store in the dB. (before any markup or programming).
2. Read some articles or books on basic database design and architecture. (This is a huge subject, but if you get the jist of index tables and joins etc you will be on the right track.)
3. Using this info, map out your dB structure. On paper or in a spreadsheet format - Think about forward compatibility (ie how will this strucure do if it grows? will it work well with future designs? is it easily upgradeable? etc.)
4. Also give some thought to the names of tables and fields. This will help later when remembering them or accessing from forms (ie naming <input>s the same as field names and building your queries dynamically).
5. Once you are satisfied with your foundation (dB) then begin to buid your UI.
You may still go back and alter a few things that weren't apparent at the time, but this will save you mad development time (and a few headaches) and your database will be easier to maintain and update in the long run.
I just found that when you redesign a site a good solid dB design will save you the time of redesigning that as well.
Hope that helps.
peace.