On my server side I need to store user data somehow. Some time ago I used to use INI files for writing and reading those values. Even with tousands of files it was incredibly fast (ms), maybe due to caching. Recently I am considering some DB but I am not sure how fast it is. That old "INI" method was easy since I directly tell the program "Load UserJohn.ini and read item PASSWORD". With DB I would need at first select the record with player name and fetch the values...really have no clue if its slower or faster than the file approach...Please ignore aspects like security, I would like to know just your oppinions on speed, thanks!
Asked
Active
Viewed 2,008 times
0
-
Depends on volumes really, how many records are we talking about here? – Chopper3 Dec 22 '09 at 13:20
-
Lets say its around 100k. – Dec 22 '09 at 13:23
-
How many did you used to have when it worked quickly - oh and what OS were you talking about then and what now? – Chopper3 Dec 22 '09 at 13:25
5 Answers
1
If you are going to be storing LOTS of records, then having an indexed table can definitely speed things up. A lot of super simple databases are in-process and generally not too keen on sharing connections, so if they are used in a web application (or just lots of concurrent threads) a lot of those databases can start having real issues.
There are other trade offs as well, such as not having to reinvent the wheel and just general code maintenance.
Goyuix
- 3,214
- 5
- 29
- 37
0
I would say files will be a bit faster if cached. It is direct access while with any DB you have to connect, send command, wait for reply and proccess it.
0
For the volumes you mention, a database will probably be faster since you can index the tables. It depends, though, on if and when you cache the .ini file. If you have the luxury of caching the file once when the process starts, that method may be faster. However, if you have to repeatedly reload the file, the indexed table in the database will probably be quite a bit faster since it doesn't have to load the entire file when it's accessed in order to pull out a single row.
Ed Leighton-Dick
- 1,094
- 1
- 7
- 12
0
In something like 100K worth of data, it's not going to be the file access that's going to be the difference per se but the way the data is organized vs the way its used. In your example the same type of code could be used on both the sql Ce and text files (w/ ado.net) but if each record had 15 fields the indexed table will retrieve the correct record faster than a text file can be parsed to locate the same record. However as the number of fields gets smaller so does the performance gap. The performance gap is usually even greater when considering updates to records. Another benefit of an embedded database from a design standpoint is that unlike a general data services application, a local datastore application already knows what questions are possible to be asked. Thisw means I can create views to speed up query execution even further. Also when designing a data service application, you have to worry about how expensive (in terms of iops and performance) a query is vs a local database that can get as expensive as the user is willing to put up with.
Jim B
- 24,081
- 4
- 36
- 60
-1
If you want sql language capabilites, and don't want a sql server running, use sqlite[1] instead of sql ce.
[1] https://stackoverflow.com/questions/583278/sqlite-vs-sqlce-vs-in-a-mobile-application
