Retrieve static data from database vs. file system

Question

I am about to start a project using ASP.NET MVC. As part of the project, we need to display some data to the user. The data consists of an object graph that consists of 35 days per line. Each day can be a work day or off day. If it is a work day, there could be additional information associated with the work day. So basically, we have an html table with 35 columns and 4 rows for each of the lines (object graphs mentioned above). There can be up to approx 300 of these object graphs per user.

The data inside these object graphs never change. For obvious performance reasons, we are only displaying 20 lines per page with an ajax call to retrieve successive pages on users request. So we have 20 of the above mentioned tables per page request.

For performance reasons, we can generate the html for each of the above mentioned tables off line and we want to put them in a database or deploy to the web servers directory. My question is what is the performance implications for having the html in a database table and having a controller send the html back to the client on an ajax call vs. having the html fragments on a known location in the web server and client request the fragments via a http get request? Is it even possible for an ajax request to retrieve a file from the web server and change the inner html of some DOM object?

Thanks in advance for your answers.

Answer 1

Put the static HTML on the filesystem. Really. You're just going to bloat your database if you put it in the database, and the contention involved in getting the database connection and retrieving the data is not worth the additional load on the database. Databases are, in general, much more expensive than plain filesystems; it's easier to add filesystem space than it is to upgrade your database because you've run out of space because you're cramming unnecessary static data in it.

Answer 2

A lot of this depends on the size of the html fragment. Most likely it's small enough that fetching it is going to be relatively quick and storing it in the DB will work and it's not worth the hassle of dealing with out of DB objects. For larger objects it doesn't make sense. Exactly where the cutoff is depends on a lot of things.

Sounds to me like the html chunks are pretty small and it's probably best to keep the html in your DB.