On 2 Aug 2010, at 2:48am, Nikolaus Rath wrote: > Roger Binns <rog...@rogerbinns.com> writes: >>> I was wondering why there isn't a hash function build into SQLite. >> >> Firstly note the last 4 letters of the name. It is indeed a fairly frequent >> lament here that SQLite should include some functions the poster thinks is >> generally applicable. Did you know it doesn't include a string reverse >> function as standard, nor any of the trigonometry ones, not even square >> root, is missing many potentially useful string functions and even omits >> statistical functions like standard deviation, median etc? > > No, actually I did not really notice until now. But now that you say it, > trigonometry and statistical functions really ought to be included as > well!
SQLite is a database engine. Neither trig functions nor stats functions improve the handling of data. If you want trig and stats, dig up one of the many trig and stats libraries. If you want SQLite to do them internally, write some SQLite extensions. That way you can have them when you want them, but I don't have to have them when I don't. > I don't see the point for a string reverse though, what would you > need that for? Searching for words by their ending. So you can quickly find all words that end in 'ly', for instance, without having to store every word twice. Ironically a feature I might actually use. Almost all uses of SQLite are as a trivial part of another application on a desktop computer (e.g. Mozilla) or embedded in hardware (e.g. a mobile phone). Any big programming environment on a desktop computer has trig and stats functions implemented already, so they don't need them in a database engine. Any small programming environment is small because users want it small, and making SQLite big means they have to use a more Flash memory, which means increased cost, weight and bulk of the finished product. There are legitimate arguments for building certain facilities into SQLite because they increase the power of the database engine for doing its job -- handling data. For instance, including certain ICU (International Components for Unicode) functions would mean that SQLite could handle many other languages as well as it can handle English. That would be a big win for all manufacturers trying to market their products in more than two countries. But frankly I'm not even sure that abs(), round() and soundex() should be in SQLite. I wonder how they ever made it in. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
