Search and Rescue: 7 Reasons for SQL (and N1QL) Developers to Use Search

People don’t want a four key index. They need a four-ms response. -  Ted Levitt

Application development is demanding. Each application is trying to progress on behalf of the customer — searching for the right product or the right form, ordering, canceling, shipping, checking the status, etc. The typical query and B-Tree-based databases and infrastructure are suitable for developing many of the modules. Still, there are cases where SQL and B-Tree-based searching is ineffective in meeting your SLA. Here are the seven problems you’d encounter in SQL development and solutions for them using search technology. I’ve used Couchbase N1QL as the SQL implementation example, Couchbase GSI as the sample B-Tree based indexes (logically speaking), and FTS (Couchbase Full-Text Search) as the example search technology. I’ll also use the travel-sample model and data in the Couchbase sample dataset in the examples.

Developer Challenges

1. The NAME Search Problem (aka the LIKE Problem)

Social media may like to like often, but SQL doesn’t. Like predicates are one of the first things to look at when they’re used in a query. Without careful usage, the LIKE predicate will increase your latency, bring down your throughput, and shut down your operation. Here is a sample of LIKE predicates that I’ve seen in real customer applications.

from DZone.com Feed http://bit.ly/2vyu2ks