Sorry but I don't agree at all. Here's a few reasons why:
- A database is a method of efficiently storing, searching, and retrieving large amounts of tabular data (ie. data that can be laid out in a table or grid). None of mIRC's internal settings or files use tabular data, so there's no sense in making these files rely on an SQL backend.
- The biggest speed limitation in accessing a file is the time it takes for the hard disk to retrieve it. SQL software cannot magically make the hardware any faster than another program, the way they speed things up is by using caching and indexing. INI files are already cached and by their nature are indexed.
- Comparing SQL tables to variables is silly. They're two completely different things and variables should always be faster to access than an SQL record. Far faster.
- INI files are easily human-readable and with very little understanding can be edited in a text editor. SQL table files are not human-readable and absolutely cannot be edited by hand unless you understand the details of the format in use. A minor point but one that I'm sure would bother a few people.
- I doubt very much that hash tables are slower than using an SQL database. I'd love to see how you came to that conclusion. If they were slower it would only be because of a problem in the algorithms currently used in mIRC's implementation of hash tables. By concept alone hash tables will be faster than SQL tables for accessing an item by it's index. In theory they could be slower for searching since SQL uses indexes but hash tables as implemented in mIRC actually have more powerful searching capabilities than SQL provides (ie. the ability to search the entirety of an arbitrary length value instead of a pre-determined length of it).
- Having separate variables per script has nothing to do with the way the variables are stored, it's just the way the scripting language is designed.
This reminds me of a few years back when XML was all the rage and people were saying mIRC should use XML to store settings since it's newer and better than INI files and all programs were switching to storing data as XML. Several of the same arguments applied to that (no faster, unnecessary for this type of data etc.) and if you take a look around now and you'll find very few programs that use XML for data unless they genuinely need it.
It's a common situation that when someone gets a hold of a new round peg they'll try and fit it in every hole, no matter what the shape. But I think if you consider the points above you'll realise that SQL doesn't make sense for mIRC.
