From: Alexandre B. S. <ib...@th...> - 2004-06-24 21:35:35
|
Hi Peter, Thanks for your time reading and answering... Peter Jacobi wrote: >It is (in my opinion) a defect in the Firebird code, that >like "Alexandre%" (and equivalently STARTING WITH "Alexandre") >doesn't work for you. For every multi-level collation it should matches >ALEXANDRE and alexandre and Alexandré etc. > >I don't judege it to be wise, to add a large number of collations to make >up for a code defect, which can easily changed, if only we agree that >it is a defect. > > > Agreed ! I don't know if the solution are create distinct collations to solve the problem. I don't know very well where the problems lives. The problem I encounter is: I'd like that firebird search/order in a case/accent insensitive manner, and that the search works as expected with like, containing, starts with, or any other future operator created. >Then why don't you implement one or let one commercial programmer spent >four commercially paid hours to make your commercial application work >commercially? > > > I have no knowlodge of C or knew how FB works internally, I have never been involved in dbms design/coding, so I think I cannot do it by my self. As Carlos mentioned Paulo Henrique Albanez, have done a modified version of FB that order/search as we Brazilians wish, we like it to be implemented on main FB Tree. He did some fix and "like", "starts with" and "containing" works as expected. But AFAIK the change he made are not in acordance with FB code rules. So it cannot be merged on main source tree. I think I can raise some funds if someone wish to solve the problem, don't even dream how much will be this cost, maybe what I think I can raise will be way low then what someone wish to do the job. In the other way, I have dealed with it for some years, so if the developers think that this issue should be addressed on FB 2.0 that's ok for me, I prefer a "good solution" that works than a "perfect solution" that will just be avaible on FB 5.0, but if the time/cost involved in developing a "good solution" are almost the same as develop the "ideal solution" I understand it perfectly, and just hold my breath for sometime. Just a side note: Don't take my words in any negative or destructive criticism, I don't have full control of the language, so I think sometimes my comments could be interpreted in the wrong way. :-) >I'm doing this as a hobby of mine and I am more interested in >linguistically correct sorting. > > > I noted it in your comments about the Thai implementation you did. :-) >The most generally rule I found, is that 'foreign' characters should be >mapped to their nearest ASCII equivalent, but that some or all of the >non-ASCII characters of your own language are considered distinct. > > Did understand what you meant here... >If you expect users, who will only want to enter ASCII characters for >searching, are the same users doing the data entry? Then can you trust them >the enter the non-ASCII characters correctly or should the database >better store only ASCII characters. > > They will search with both ascii/non ascii, what we wish is that these words João Joao JOAO JOÃO jOão joÃo etc. Will be considered the same for sorting/searching, does not matter how the user input the field or how he asks in the search, any one of this forms should be equal to all the others. The database should stored the data as the user typed it, but are far more readable, elegant and correct the mixed form with the proper accents. But if the user type "JOAO" the data should be stored as "JOAO", when he search for "João" the record should be returned, but as typed (without the accent and upper case). The users should type it correctly. >So the remaining use case for a very aggressive no-accent collation seems >to be an application, where data entry is done very carefully by users, who >are aware of character details, and searching by users who only know ASCII >or are forced to use as system where it is hard to enter non-ASCII >characters. > > > The idea is: Does not matter if one user typed ith accent and mixed case, the other type with accent in upper case, and a lot of records was pumped in the database from a DOS app that just uses upper ASCII, he can search it in any way. The ability to enter accent chars in mixed case make the reports more candy to read are with a professional look, when you send an invoice to a costumer with all caps withou accent it looks ugly. So, the ability to enter the especial chars are very desireable, but have a drawback, that if there is no pattern, or if the data could have legacy records, one should search in every form to find a desired record. >Fine. So you see, Firebird INTL architecture allows easy additions specific >to your needs. > >The above can also be achieved using the LOADABLE collation of my pjcolkit, >but as residing in fbintl2 and not in fbintl, it is somewhat more awkward >to use. (http://www.jodelpeter.de/i18n/fbarch/loadable.txt) > > I have readed it, found it very usefull, I am waiting for the release of the "brazilian version" of FB 1.5 that Paulo is working to do some tests, and decide wich option to adopt. I have looked in the a long time ago about Dave's collation kit's, but the kit's was just avaiable on Win, and the majority of my customers use Linux, I wish a consistent behaviour in all of then. >There is a non technical point to consider: > >Some aspects of collations are just tedious, stupid work. So you can expect >a lack of volunteering in OSS projects. It's like the situation with fonts: >There are a big number of free fonts, but almost none of them look good >at small point sizes (some even look ugly at all point sizes!), because >this would require a large amount of "hinting", which is a very, very >tedious and stupid work. > > I have this feeling, and this feature are not so important to a greate number of people (english users, etc.) but I think the latin derived language users wish it a lot. >Regards, >Peter Jacobi > > > > see you ! -- Alexandre Benson Smith Development THOR Software e Comercial Ltda. Santo Andre - Sao Paulo - Brazil www.thorsoftware.com.br |