> Pavel said: > >Hi, all. > >Traditionally, SQL databases are case insensitive, or at least have an > >option to behave this way. Sqlite is case sensitive and this fact is > >introduced in a lot of places in sources. Having case-insensitive > >sorting and matching seem to be extremely useful thing to me (in > >business domain where one have to deal with names, addresses etc). Any > >opinions? > >Yours, Pavel > > Personally, I prefer that databases *are* case-sensitive by default, as this matches how most programming languages work. > > If I do a normal comparison between two strings in a programming language, they match only if the case is the same. It gives me plenty of headaches if the database behaves differently, and I can't be certain if matches returned by a database actually are matches. > > Also, case-sensitive comparisons (basis for both matching and sorting) are considerably faster and use less memory than non-sensitive ones, since with the latter one has to convert the string on each side to either an upper or lower case representation, so that the normal numerical comparison of the strings match, and with the former, no conversion is needed. > > Also, in these days of increasing internationalization, it is simpler to do case-sensitive by default since that's what all the world's other character sets and our own non-letter symbols do, to my knowledge. > > Now I do recognize the value of case-insensitive comparisions, but I think that this should be done as a type of extension functionality rather than in core functionality. > > What I mean is, have a different syntax to specify case-insensitive matching, much in the way that "like '%abc%'" is used when we want to match just part of a string. > > Also or alternately, treat case-insensitive operations as a locale-related thing, much as parts of a database schema can be configured to do things in a certain way, such as sorting, based on the user's locale. > > So case-sensitive default actions all around are the simplest, fastest, take the least code, are the most reliable, and technically most standard way of doing things. So I see SQLite doing sensitive by default as a good thing. > > -- Darren Duncan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
I'm in the opposite camp I'm afraid - I find case sensitivity irritating for both database and programming language and also, a little unneccersary. Most real world database applications have to provide some level of textual searching to their users, be it names, addresses etc. Case sensitivity is a major pain in these circumstances. I've been working with text management systems for the last 12 years where this issue is normally managed on a per column basis through the index i.e. you define an index for a column to be case insensitive and the search terms are adjusted accordingly when a query is run. Therefore, the performance of case insensitive searching is NOT slower because the search terms in the index are stored in upper case - when the query is run, the user terms are converted to the same case as the index terms prior to looking them up in the index. I'm not sure where the drop off in reliability is that you refer to in this scenario........ To be honest, this sounds like a pretty simple change (but then, don't they always) to SQLite to be able to provide a pragma that switches this feature on/off for all indexes. Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
