Not logged in (Log in or Sign up)


Your comments, please

So, next on the list is...

  • comments

As a database developer, I'm used to normalizing the hell out of my data. So, when it came time to implement my blog, I was convinced that posts and comments were the same thing. A comment was just a post with a parent post. One advantage of this, was that it inherently supported threaded comments... ie. replying to comments rather than the original post.

However, when I attempted to do it that way, I realized that I lost a lot of the simplicity that is in Rails. For example, when generating a url to create a comment, it would instead generate the url to create a new post (since, the object being posted was in fact a Post).

I could solve this a couple of different ways.

First, I considered using single table inheritance. This would solve the problem of automatically detecting the type... but, was a comment really a post? Let's look at the attributes...


  • title
  • body
  • extended content
  • permalink
  • published flag
  • locked flag
  • author


  • body
  • approved flag
  • author

There is definitely some clear overlap, so I could use this approach.

However, the alternative is to simply use two different tables (and models). I decided that a clearer separation of the two would make the code easier to maintain... validations could be clearly defined in the appropriate model and no tricks would need to be played. So, I'm using this approach... if need be I can merge the two in a future migration, but I'm betting I won't have to (or want to).

How do you make decisions like this?


blog comments powered by Disqus