Adding SQL to mIRC would really just bulk up a good client with stuff that the majority of users would have no use for. For the relatively few users who might use SQL, the DLLs already cover that for you.
For the person who decided to use some random program to test the speed of accessing data, that's not a valid method. If you really want to do a speed comparison, you need to have the exact same data stored in each method and perform the same search on that data. And, for comparing speed, you use $ticks to calculate how long it takes. Being part of mIRC, $ticks offers a "clean" way to calculate speeds without worrying about the quality of other software. Now, I can tell you right off that SQL *will* be faster than text files and probably somewhat faster than INI files, though that will probably be fairly close. However, hash tables and/or variables will be considerably faster than SQL in most situations, assuming you have them set up well. The main situation where it will become an issue with when doing really specific wildcard searches on the data in the hash table.
Regarding using "$gettok hacks" to deal with many "columns" of data... first of all, if you have 70+ "columns" per item, you really should consider a better storage method as that's not very efficient. Second, using /tokenize may save you some headaches depending what you're doing.
Personally, I don't think mIRC should become bloatware by adding support for every possible thing you can think of if it really isn't necessary. That's what DLLs are for.
