views:

81

answers:

2

I am looking at databases for a home project (ASP.NET MVC) which I might host eventually. After reading a similar question here on Stack Overflow I have decided to go with MySQL.

However, the easy of use & deployment of SQLite is tempting, and I would like to confirm my reasons before I write it off completely.

My goal is to maintain user status messages (like Twitter). This would mean mostly a single table with user-id/status-message couples. Read / Insert / Delete operation for status message. No modification is necessary.

After reading the following paragraph I have decided that SQLite can't work for me. I DO have a simple database, but since ALL my transaction work with the SAME table I might face some problems.

SQLite uses reader/writer locks on the entire database file. That means if any process is reading from any part of the database, all other processes are prevented from writing any other part of the database. Similarly, if any one process is writing to the database, all other processes are prevented from reading any other part of the database.

Is my understanding naive? Would SQLite work fine for me? Also does MySQL offer something that SQLite wouldn't when working with ASP.NET MVC? Ease of development in VS maybe?

+2  A: 

If you're willing to wait half a month, the next SQLite release intends to support write-ahead logging, which should allow for more write concurrency.

Tangent 128
Thanks Tangent. I checked the link and it seems like good step for SQLite. But, I don't think I should wait, least my enthusiasm dwindle!
Preets
Depends on your timeframe. If you don't expect heavy usage in the next two weeks (it being a home project and all), you could just develop for SQLite and update the library then.Or just develop in MySQL and port to SQLite later if the next release proves worthwhile. If your database code is sane, a one-table app should be easy to translate.
Tangent 128
Thanks Tangent. I'm going to work with MYSQL and port it if needed to SQite once the new release is out and acceptable.
Preets
How many processes are going to be writing to the DB? If it's a single front end that handles multiple requests and does the updates then SQLite is fine. If you have multiple front ends all talking to the same DB then you probably want a full DBMS anyway
Martin Beckett
+1  A: 

I've been unable to get even the simple concurrency SQLite claims to support to work - even after asking on SO a couple of times.

Edit Since I wrote the above, I have been able to get concurrent writes and reads to work with SQLite. It appears I was not properly disposing of NHibernate sessions - putting Using blocks around all code that created sessions solved the problem. /Edit

But it's probably fine for your application, especially with the Write-ahead Logging that user380361 mentions.

Small footprint, single file installation, fast, works well with NHibernate, free, public domain - a very nice product in almost all respects!

Tom Bushell
@Tom, - I've been unable to get even the simple concurrency SQLite claims to support to work - even after asking on SO a couple of times.That is discomforting. I am going to simply stick with MySQL for the moment. Thank you for your response.
Preets