Design Considerations

[Jonathan Wood]

I have an idea for several Web sites that would involve articles that can be
read. Article lengths will vary from short to a little longer, but nothing
really long.

I'm wondering at what point does it make sense to include the articles as
data in a database, and at what point does it make sense to include a
reference to the article in the database but to have the actual article as
an existing page.

Looking at sites like codeproject.com, it appears that the articles are not
stored within the database other than a reference to the existing page. But
I'm looking for ideas on this.

Thanks!

 

[sloan]

I worked on an applicaition that did both.

The "master" was stored in the db.
But.... the user could "publish" the file, which hard wrote it out to a
file.

This gave the user the ability to edit it, but not publish it until ready.

The system was based on users being able to modify the documents,
so.............it was worth the extra work.

...

Anyone who wanted the page, would always bring up the static/"published"
page.... mainly for performance reasons.

...

as a side note, persisting the page to the database helped with a trusted
storage mechanism.... aka, not relying on files to persist the data.

...

 

[Li-fan Chen]

Hi Jonathan,

Basically what sloan said. Article submissions are stored in the master db
asap. Create a Windows service daemon to watch the DB for new articles, and
act on them every 100ms-5 minutes, if one is created, the daemon will render
it out to the file system. Logic needs to exist to rerender pages that links
to this new article.

Your IIS server will serve static pages a few times faster than ASPX pages:
with this publishing scheme, you'll serve five times or more customers per
second on the same box. But it's worth noting one shouldn't over-optimize,
make sure your server is bogged down first. Do please let us know how things
works out.

Best personal regards,
-- Li-fan

P.S. Depending on your needs, it may serve to spend your time caching db
requests, instead of caching entire pages.

Li-fan Chen
Software analyst/developer, Entrepreneur
Markham, Ontario, Canada

 

[Ben Fidge]

I'd also point out that data stored in a database has some advantages over
static pages, although not performance-wise:

- Raw data is easier to manipulate and work with than data rendered on a
page. For example you may want to expose the data via a web-service or RSS
feed.
- Sql Server has full-text indexing built in which will allow you to provide
some pretty powerfull search functionality for your users.
- Maintaining relationships between documents and categorising is generally
easier than using the file-system. Ie, a particular article record can
easily be associated with multiple categories using tables, but a static
page can only exist under one folder.

I've been working on internet and intranet based Content Managment Systems
developed in-house for over 2 years now, and agree with the other posts in
this thread. Keep raw "master" data in the database, but render this to
static pages for performance benefits.

Ben

 

[Jonathan Wood]

Thanks. I will be the only one who can modify the articles. Although, I may
consider allowing users to submit articles in the future.

So I'm not sure how well the lessons of your application would apply to
mine. If users did not need to have the ability to modify articles, would
you do things differently?

Thanks again.

 

[Jonathan Wood]

Hmmm... Like I told sloan, I don't necessarily need the ability for users to
modify the articles, although submitting may be a future consideration.

Unfortunately, I have no idea what a Windows service daemon is. I'll print
your response and review it later.

Thanks.

 

[Jonathan Wood]

Thanks, I don't understand some of the details of your suggestions but will
also save your response.

 

[Darren Kopp]

At the minimum, I would have ASP.NET cache the output of the page,
rather than hitting the database on every page hit. You can determine
how long it caches it based on your needs, but i would tend to agree
with the other suggestions already posted.

Best of luck,
Darren Kopp
http://blog.secudocs.com/