CeleriQ Real-world

As a real-world talking point, assume that we have a database of automobiles. This is an excellent example because there is some much data one can use to filter results. Each auto has a make, model, year, engine size, color, mileage, condition, feature set, location, dealer, etc.

First we define the items we call dimensions. A dimension is some non-unique data point that identifies an aspect of the primary object (listing) that can be used to filter results, like make or model of an automobile. There are a limited number of makes associated with automobiles: Ford, Toyota, Honda, etc. It is also an important piece of data, since most people buying a car want to know this information. We can define the dimensions of make, model, state, city, etc. Users will search in different ways. Some people think of narrowing by state first and other by make. In other words, there are many paths one can walk to get the exact same result set. One user might narrow by state, make, mileage, and finally price. Another user might narrow by price first then look what is left and only then think to narrow by location and other data. In any case you get to the same result set by in different ways.

The CeleriQ engine allows you to post queries and return a result set that matches your criteria; however that is where the similarity to a relational database ends. It also returns dimension data that can be used in the next search. In the example above where there are no Toyotas in Kansas, the results of search by state Kansas would yield a dimension set of type "make" with a value of Ford but not Toyota. When a software developer is using this data to build his hyperlinks, he will create one for Ford and nothing else because the engine has not returned anything else. There is no sense in creating a hyperlink for Toyota, since when the user clicks it the results will be empty. In this way you never give the user a chance to get an empty set and be confused.