Data Base selection Help for VB

[pankaj.garg]

Hello,

Please help me in selecting a database to use with VB6.

my application will store some 20-25 values each second (24 X 7) along with date-time stamp...and i would need to access this data for over 1 year period...

Keeping this in mind...which database should i select?

also please guide me as to what should be structure of my table (should i keep separate database for each month or shall month be part of table etc.)??

As i am just starting the development, please suggest the best practices :)

[vb5prgrmr]

Some simple calculations...
20 * 60 = 1200 * 60 = 72000 * 24 = 1728000 * 365 = 630720000 / 1024 = 615937.5Kb / 1000 = 615.9375Mb / 1000 = .6159375Gb
25 * 60 = 1500 * 60 = 90000 * 24 = 2160000 * 365 = 788400000 / 1034 = 769921.875Kb / 1000 = 769.921875Mb / 1000 = .769921875Gb

Which means that if you will be capturing a minimum of .615 to .769 Giga bytes of information. That is if each of your 20 to 25 fields are bytes and only bytes. This does not account for any unique fields like identity/autonumber fields which are a minum of four bytes for each record. Then there is your datetime stamp which is going to be eight bytes per record.

So what does all this mean? Well, you are going to have to figure out what each field is going to be and how much data that type takes up. Then once you have your record size, you can simply do the above calculations to figure out the minimum amount of disk space you need. Once you have that, you will then have a better idea of what kind of database you can use.

But that/this is not your only consideration when it comes to performance. Since you are going to be adding records every second, your machine will need a decent amount of ram because of the lag time between OS/server and hard drive read/write times.

As for what I can see with what little bit of information you have provided you will at least need a DBMS that can handle at least two gigs of data so you can throw Access out and probably MySQL. Which leaves you with the higher end DBMS like SQL, Oracle, and so on.

Good Luck

[pankaj.garg]

Thanks...this has given me atleast a heads up...now v can thnk along lines...

any more suggestions invited..

Some simple calculations...
20 * 60 = 1200 * 60 = 72000 * 24 = 1728000 * 365 = 630720000 / 1024 = 615937.5Kb / 1000 = 615.9375Mb / 1000 = .6159375Gb
25 * 60 = 1500 * 60 = 90000 * 24 = 2160000 * 365 = 788400000 / 1034 = 769921.875Kb / 1000 = 769.921875Mb / 1000 = .769921875Gb

Which means that if you will be capturing a minimum of .615 to .769 Giga bytes of information. That is if each of your 20 to 25 fields are bytes and only bytes. This does not account for any unique fields like identity/autonumber fields which are a minum of four bytes for each record. Then there is your datetime stamp which is going to be eight bytes per record.

So what does all this mean? Well, you are going to have to figure out what each field is going to be and how much data that type takes up. Then once you have your record size, you can simply do the above calculations to figure out the minimum amount of disk space you need. Once you have that, you will then have a better idea of what kind of database you can use.

But that/this is not your only consideration when it comes to performance. Since you are going to be adding records every second, your machine will need a decent amount of ram because of the lag time between OS/server and hard drive read/write times.

As for what I can see with what little bit of information you have provided you will at least need a DBMS that can handle at least two gigs of data so you can throw Access out and probably MySQL. Which leaves you with the higher end DBMS like SQL, Oracle, and so on.

Good Luck