Planning
12 Jun 2009 @ 01:48PM

Updated: 25 Jan 2010 @ 01:50PM
When building any web application of any size, it's important to figure out what exactly you're trying to accomplish. Though I've glossed over the planning phase in the previous tutorials, planning is arguably the most important part of any programming project. In the case of this blogging application, I've laid out a few basics on the previous page.

"This will allow a user to post blog entries, to display these entries to other people, and to allow other people to post responses."

Let's enumerate them to make things easier on us later:
  • Allow a login
  • Allow logged in user to write blogs
  • Allow everyone to view blogs
  • Allow everyone to respond to blog entries
  • Allow everyone to see the responses and respond to them

So just from the one sentence we've managed to dredge out 5 requirements. From that we can plan out our database structure.
Comments (0)
Let's make a list of what we need to do with the database.
  • A user table including the following fields. If we just wanted to support a single blogger, we could potentially hard code this. But let's make our app configurable to have multiple bloggers.
    • userid : unique field
    • username
    • password
    • display name - to associate with blog posts
    • email - for blog posts
    • show email - option to display email address on blog posts - yes/no
    • create date
    • access level - assuming multiple bloggers, we would need to be able to add new ones. However, we probably don't want all bloggers to be able to add new bloggers, so we need this field.
  • A table to hold blog entries. Entries should contain the following:
    • blogid: unique field
    • userid - linked to user table
    • blog title
    • blog text
    • visible - should this post be visible to the world? yes/no
    • create date
    • display date - the date to display as being the created date (it may be different than the date the blog was actually created if it took several days to write)
    • modified date - the last time the blog was modified
  • A table to hold comments from viewers.
    • comment id: unique field
    • userid: if a blog author is commenting, we want to highlight their responses
    • blogid: what blog is this a comment about?
    • parent comment: is this a comment replying to another comment? This will tell us which
    • name: If this isn't a blogger, get a name to associate
    • visible: this will let us 'hide' inappropriate comments without deleting them
    • comment text
    • comment date

This gives us a good starting point. As we build the app we may realize we need more fields and can make changes to the table structure as appropriate. If you got lost during this planning phase, don't worry too much about it. I've been building wep apps for years so I have a bit of experience. Just know that you should sit down, write out what you want to accomplish, figure out what you need in order to accomplish it, then move forward. Physically writing it down may not be a bad idea... personally I usually just keep it in my head, but sometimes bad things happen when I forget something important.
Comments (0)