Retain information without a database?

Question

0.00/5 (No votes)

See more:

I have a class library that uses a web refrence of a web service I made. The web service has a property, to use a Database or not to use a database. If I use a database it retains the information. But I am worried that because the web service constantly insert and delete information, using the Database will become the bottle neck of the program.

So my goal now is to have my information be retained through OS refreshing of the service. Any idea how to do this?

Also I am an CS student who is going to their sophomore year, and currently an intern just for the summer. Learned C# and used Visual studio for the first time during this intern. I love it! Also the guy that is supervising said he will be busy and if I need help, I could use this website!

[UPDATE]
In my web service I have

public class Service1 : System.Web.Services.WebService
   {
       private SqlConnection connection;
       private List<ListData> ListOfMessages;
       public Service1()
       {
           if (Properties.Settings.Default.UseDatabase)
           {
               try
               {
                   connection = new SqlConnection(Properties.Settings.Default.DbConnectionStr);
                   connection.Open();
               }
               catch (Exception ex)
               {
                   Console.WriteLine(ex);
               }
               Dispose(false);
           }
           else
           {
               ListOfMessages = new List<ListData>();
               Dispose(false);
           }
       }
}

Posted 8-Jul-11 10:08am

Member 8015046

Updated 8-Jul-11 10:24am

v2

Add a Solution

4 solutions

Solution 3

The best thing to do is to define your service around an interface:

public interface IRepository
{
    void AppendData(string name, string value, DateTime timeStamp);
    string[] GetData(string name, DateTime from, DateTime to);
}

Then you will have concreate implementations:

public SqlRepository : IRepository
{
    void AppendData(string name, string value, DateTime timeStamp)
    {
        // SQL implementation
    }

    string[] GetData(string name, DateTime from, DateTime to)
    {
        // SQL implementation
    }
}

// Similar for MemoryRepository.

Then it will be easy to select or compare each possibilities. You could also implement other possibilities like SqlWithCacheRepository where you keep mostly used data in memory.

Posted 9-Jul-11 11:02am

Philippe Mori

Comments

Member 8015046 9-Jul-11 18:46pm

This seems very interesting. I am going to look this up more. Do some speed test on it. Thanks for the idea!

TRK3 11-Jul-11 10:21am

Good concrete suggestion. Probably exactly what OP needs to show him how to implement it now and change the data store later when he finds he needs to -- which is what I was saying. My 5.

Solution 4

I just saw the following article on online MSDN magazine. I haven't read it yet but I though that might interest you.

Master Large Data Streams with Microsoft StreamInsight

http://msdn.microsoft.com/en-gb/magazine/hh205648.aspx[^]

Posted 11-Jul-11 14:07pm

Philippe Mori

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

TRK3 · Accepted Answer · 2011-07-08T10:43:00

What sort of perfromance / scale / use do you reasonably expect you are actually going to need? You might be worried about something that isn't ever going to be an issue.

Don't spend time solving a problem that doesn't need to be solved.

Databases are supposed to be optimised to support lots of transactions per second. That's what they are supposed to be good at.

You aren't going to be able to implement a database replacement that's better than a database if what you really need is a database.

If what you need is a database, then use a database.

If it becomes a bottleneck, then configure your database better or replace it with a faster database (or throw hardware at it).

If you don't need a database, then what data are you actually trying to persist? To persist data, it essentially needs to be written to persistent storage (and maybe cached on the way for faster write/read) -- but that's what a database does.

A pure read/write of a file may actually be slower than using a database.

There are in-memory databases if you don't actually care about persisting across a power failure.

Philippe Mori · Accepted Answer · 2011-07-08T14:18:00

I think that a few improvement can be done to your code:

Don't eat exceptions in a constructor. Your service object would not be "usable" if something goes wrong.
What is the Dispose call inside the constructor?
Dispose is not intended to be called from the constructor but from the caller when he does not need the object anymore.
If you want to be ready to support different data store options, uses an interface to that repository and implement concrete class for each possible case (SQL Database, in-memory database...)

In order to select which option to choose, we should have an idea of:

The amont off data returned by the service (record count and data size)
The total amont of storage
Does the returned data vary by user, by time or seldom changes?
How many request you expect per second
...

That being said, in most case a database is the only option if the data needed to be permanent or if the data is huge.

If you have a lot of data to return each time (say 1000 item or more per request) and each item is small and you don't need to index each item separatly, then it might make some sence to group some data in one SQL record. For example, one SQL record might be 1 minute of data if you record 10 samples per second.

Finally, I think that a lot can be done on the server side if you need more performance like having a web farm or dedicated hosting instead of shared hosting.

Retain information without a database?

4 solutions

Solution 1

Solution 2

Solution 3

Solution 4

Add your solution here

Preview 0