[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Reading Writing File or Query Update Database - Which one is faster in .Net

Posted on 2011-04-26
4
Medium Priority
?
459 Views
Last Modified: 2012-05-11
At the moment we have log module which is written in .Net that logs messages errors in application to seperate file every day.

Some times frequency of writing messages into log is more than 200 messages per minute.

If i change the log module so that it writes into sql database  rather than file will this be faster than writing into file ?

Advise ?



0
Comment
Question by:NetSri
4 Comments
 
LVL 39

Assisted Solution

by:Pratima Pharande
Pratima Pharande earned 664 total points
ID: 35465619
yes, wrting to database is faster
and also easy to handle and read
0
 
LVL 8

Accepted Solution

by:
colr__ earned 668 total points
ID: 35465986
Databases typically use files to store the data persisitently, however they also implement advanced algorithms to implement caching and data access etc. This makes database access much faster than standard file access.
0
 
LVL 24

Assisted Solution

by:Jeff Certain
Jeff Certain earned 668 total points
ID: 35466343
In general, it should be faster to write to the database.

The hardware is usually faster on a server. Although you're still writing to a disk, it's generally a 10K or 15K rpm drive, rather than the 7200rpm drives common on desktops. In addition, RAID controllers can make this even faster. However, if you're running a solid state drive on your desktop, that will change the balance.

Network latency is a consideration. Ensure that you're not writing the log to the database synchronously, or you'll end up waiting for the communications to/from the server. On networks I've tested, this runs roughly 1/8th second to open the database connection. This is less of an issue if you're writing to a local database, obviously.

Have a fallback plan, in case the database isn't available. Again, if it's a local database, not so much of an issue... although the local service that runs the database may be turned off for whatever reason.

Be aware that databases write not only the data file, but also (depending on configuration) a log file of their own. These log files can get big quickly. If you happen to come close to filling your hard drive (which can happen as the result of the database server writing out temporary files to process queries dealing with large amounts of data) you'll end up crippling the machine, and nothing will be fast.

You may want to consider the Windows event log as a spot to log the events to, especially if it's a local logging approach.

And, finally, databases may have a slight edge because they're aware of data types. Numbers and dates, for example, are stored appropriately. So, a number like 2 000 000 000 takes 4 bytes (32 bits) to store in a database, but 10 or 20 bytes (depending on encoding) to store in a text file.

HTH.
0
 

Author Closing Comment

by:NetSri
ID: 35496174
Thanks All
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Today I had a very interesting conundrum that had to get solved quickly. Needless to say, it wasn't resolved quickly because when we needed it we were very rushed, but as soon as the conference call was over and I took a step back I saw the correct …
Many times as a report developer I've been asked to display normalized data such as three rows with values Jack, Joe, and Bob as a single comma-separated string such as 'Jack, Joe, Bob', and vice versa.  Here's how to do it. 
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data. But that feeling is fleeting. Attacks these days can happen in many w…
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…
Suggested Courses

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question