Quote:
Originally Posted by Super Aids
Thread-safety is much harder to achieve proper with flatfiles (I assume you're referring to the winapi calls Kernel32.WritePrivateProfileString and Kernel32.ReadPrivateProfileString etc. and they aren't thread-safe.)[...]
|
The sh*tiest method to use in a database

It will reloads the file FOR EACH read, which is pretty slow. Those methods are here to work in the registry, not with INI, so if you ever INI for big task, use a real INI lib.
Quote:
Originally Posted by Super Aids
[...]I was using flat-file in that for the database and the items (was storing each item in a file for them self.) took very long to load, however when I switched to sql the loading was incredible fast.
|
Did the same in COPS v6, until I decided to go binary

I had a 100 MB items.pkg which could contains approximately 1M items. It was really fast, and pretty easy to manage. But nothing compared to a real database. (Just had to seed to the (UID * sizeof(ItemInfo)) and check for a byte).
N.B. I had a separate thread for the saving I/O in the file...
A database is almost always better for a server. I almost always used flat-files due to the cheap hosting I had, which wasn't really great when using a MySQL database. Well, at the end, I was using a lot of optimized binary files for the static database and packages/XML for the dynamic database. The performance was okay, but the thread-safety was terrible. Today, if I had the same restriction (no SQL server), I would go for SQLite. The performances aren't similar to MySQL (or MsSQL that I never used), but it doesn't require an external server and the library is really small.