ASP.Net MVC Blog content storage

Question

Hi,

I'm creating a blog in asp.net mvc for learning purpose so please no answers telling me i should use an open source blogengine. I need to understand how is the blog content going to work. So i have a table called "Blog" with a column called "Content". The "Content" will hold the blog i.e. text and images etc. Now i have the following questions:

1. What should be the datatype of content.
2. Is this the correct way of doing it i.e. saving the blog in a record.
3. What are the contants of this blog i.e. is it html with rich text and image urls and how does it actually work, i.e. where are these image urls be pointing to and how will my application render it.

Thanks.

Answer 1

Though you certainly could make it work with a single table, you probably want to use several tables to store the content. A basic implementation might look like:

• One table for the periodical list of blog entries you have with columns for blog ID, perma-link/url, etc
• One table for the tags associated with each blog id
• One table for the blog entries themselves, consisting of a blog ID, blog body, etc
• One table for comments, with blog ID, comment ID, comment body, etc

Everything would be linked together in the tables by the various IDs (blog ID, comment ID, etc) and your engine would load and render the body elements as specified by the ID requested.

Images, attachments, etc would be stored on a fileserver, and the rendered content would have hyperlinks to them.

This is by far a simplistic envisioning of it, and doesnt cover many aspects or issues. For instance, if you plan to store content such as images, etc in your DB you will need to have unique pointers for those, tables for those items and a way to resolve them as part of your MVC framework.

Start simple, and build up from there if you are just learning. Just build each table as you need it and go from there.

Answer 2

Not sure which DB you are using but assume SQL server for this example. You can store your blog content in a field as nvarchar(MAX). i dont see any issues with doing this