Last day of sprint. Again.
So, today we're releasing again. Or: we're having the internal release and the public release is tomorrow. So, today I've been testing and discussing the bugs I've spotted before. We also had some time fixing some cosmetic problems.
We've focused a lot on search during this sprint and I'm again amazed at problems with a multi cultural supported application. Take for example dates and numeric values. We need to support that users print dates and numeric values using different cultural settings. Match this to the date format in the database and visualize the culture supported result in their GUI.
We've introduced Microsoft SQL Server FullText support. That sounds nice but lot of data need to be indexed twice, for example because the wild card support only support wildcards in the end of the text string. So, you can search for something starting with and s (s*) but not ending with s (*s).
When were discussing numeric and date and search. We also need to support that you find everything starting with a value (1*) and intervals like between 1 and 10 (1..10). So numeric and date data need to be indexed both as numeric/date and text.
Google might look simple but looks is deceiving. Search is easy but finding the right stuff is hard.
posted by Anna Forss @ 3:43 PM
4 Comments:
Search algorithms can be very complex; that is why Google hires so many Phd's in Math
And that it's so good for me as a business analyst to sit in the same room as the developers: I could never have guessed how complex it is. And it's so easy for the developers to ask. For example wild cards searches are nice, but not always. We have status Not Started and status Started. And if you search for Started you don't want to find Not started.
"We have status Not Started and status Started."
Isn't that simply a bit field in the database?
well, not exactly but the problem was that we are combining the full text search with traditional sql search queries and somewhere and somehow a like query was badly formed and this was just one of the effects. The application has configurable number and types of fields so the search has also to take this into consideration: you want to search for a string independently of field but sometimes you want to search for the string if it's set on a specific field.
For example, we have cases (the order of a number of work orders) and on the case you can have the custom fields Customer and Contact, where the customer is the paying part and the contact is someone who wants to be contactable concerning the case. For example if you have a problem with an apartment where Sarah Low lives she might be set as customer on a case where she will receive the bill but if she is not going to pay, she still wants to access the case on her case portal. So, in some searches you want to find all her cases, independent if she's a contact or a customer. In other cases you want to find the cases she's going to pay for.
But in other system installations you don't set the customer on the case, you set the contract. This is apparent in the system installations were different parts of a case can be billed to different customers. So, you don't know if there is a customer field on case.
This makes the search functionality even more complex.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home