This project is read-only.

Why not SQL

Topics: Developer Forum
Feb 7, 2007 at 5:04 PM
i really love the work you've done guys. But i'm just wondering what is the advantige of using app_data for saving the user data and not in an SQL-Server
Wouldn't the performance be even better using a DB? What are the pros and cons?

Feb 7, 2007 at 11:47 PM
It's true but as developers stated this aims to be a small-scale CMS, easy to implement and modify. At least, at first.

Actually I think this means a portal for websites in the the range 1-50pages. While SQL would surely enhance scaling, this design is far from being simple. Database storage would help better concurrent updates however consider that module content is not read from disk on each request because at first requeste it will be cached. This makes retrieving it faster than loading up from DB and it works for all subsequent requests.

Moreover, the data layer has been incorporated into class definitions so this is completely transparent to user once you define your data class, plus it will be fully object oriented (this means you can store hashlists or dictionaries or sorted list the same way they are used in your code). It then gets easier to handle those data rather than filling your business objects with data from DataSets (or DataReaders or pass them around). Drawback for this is you need to retrieve the whole objects even if you need part of it while a DB can read only rows you actually need.

Finally, sections (modules) are super-easy to develop given the easy DAL and super-easy to mantain.

I guess we need to wait and see in order to measure performances and understand which is limit of this design. However, I wouldn't be suprised if this design, expecially because of widespread caching, could be able to handle quite high loads...
Feb 8, 2007 at 4:21 PM
Edited Feb 8, 2007 at 4:21 PM

Let me add here some additional reasons about why we decided to avoid a database for MWPSK:

  1. Deployment of a website to a hoster with a database is cumbersome because you usually cannot access the database directly. Deployment of a website with MWPSK is only a matter of uploading all files through FTP – done. One key objective of MWPSK is to offer a successful first hour with ASP.NET technology. The DB deployment perhaps has a big negative impact during these first steps.
  2. Maintenance of a database in a database server at your hoster is difficult. If you want to duplicate the production DB on your local machine you might have to ask your provider to send you a backup of your DB. And then you need to apply the correct RESTORE command…
  3. Hosters often charge extra fees for a SQL Server DB. You don’t spend this money with MWPSK.
  4. We tried to keep the code as simple as possible. Avoiding the relational DB did save a lot of code.

However, SQL Server databases have a lot of advantages as well! Many of the above issues only apply for small websites. As soon your site is growing it is worth the effort to overcome them.