There's only one function you need to know to write, one for read (for strings).
With MySQL you have to worry about live connections (and the multithreaded connections, although INI files aren't thread safe themselves considering the file could be already an open handle elsewhere). Connections can be already in use, or dropped, and can't 'die' if over-spammed. In order to read a file you have to use a query to make a data reader, then query from the entry in the table. In order to read a value from an INI file, you call one function (assuming this from a C/C++ background where you can directly call a native function without having to marshal parameters etc).
Not arguing about speed, that wasn't my point. Text files are actually faster to parse if you need one thing of data at start-up than actually making a live connection and sending queries only to be closed again. The only thing that makes ini's slow at reading an entire
character data is the fact that the win32 API opens and closes a file every time you call a read/write function to an ini (Write/ReadPrivateProfileString) and that it needs to parse out every string until it finds the right section/key.
My point is about using them in a program, not the speed or what you think of them, stop straying from the argument here.
To quote one of your idols (and make a point):
Quote:
Originally Posted by unknownone
It's not opinion that binary files are grossly better for performance, It's hard fact. Are you trying to teach us something new? Because this is the basic of the basic.
|
And if you didn't know SQL database use structured binary files (structures depending on the table).