Piloted Search is the defining feature of the Celeriq engine. It allows you to easily build a Win or Web application that gives users the ability to pilot the search instead of relying on canned reports.
It is customary when building software applications for developers to decide how someone will use the product. With Piloted Search, the user can decide for himself where he wants to go and how he wants to view the data.
This adds a lot of functionality to applications with virtually no coding. It is all provided by the Celeriq engine.
Dimension data can be ordered in different ways according to your business rules. For most data, you may might want unique dimension data to be ordered alphabetically; however there are times you may also want it to be ordered by number of matches found. In addition to dimension sorting, there is also record sorting and aggregate sorting.
Pagination is built-in. You only need to specify the page index and records per page. Based on search criteria and sorting, a page of data is quickly returned. This is nice feature that is not built into traditional SQL. The results are always paginated, so there is no reason to spend development time creating complex schemes to solve the pagination issue.
You can sort by any field to display custom results to users. You can also disallow sorting on fields. This gives your application architect the power to limit what software developers can do. Business rules can be codified into the engine itself so management of teams of developers is simpler.
For websites with either a large number of users or a large amount of data (or both) scalability is going to be an issue.
Celeriq allows you to scale for both.
There is never any software to install.
All functionality resides on the server so you do not have to maintain servers or install software.
Always know how many items will be returned before a search is performed. This is very different than traditional SQL. This feature allows you to know the results of thousands of possible query paths before actually performing any search. It also has an added benefit of never returns no results. All queries necessarily will return one or more results. You will never run into a null path.
Once you have designed your repository, a strongly-typed API is generated that allows you to access your data. If you ever change your application design, simply re-implement and your API matches your data repository. This is very important functionality not to be overlooked. With a strongly-typed API you will get compile-time error in your application not run-time errors. What this means is you will never ship an application with data schema errors since your application will not compile in the first place.
Dimensions can be setup in hierarchies. For example, there are tens of thousands of cities in the US. This is too much information to display to users at one time. You could setup a state dimension and make cities its child. When a search narrows results down to a single state, the city dimension would then return data for cities only in the specified state. This allows you to limit information overload.
Geo-coding is the act of defining a latitude and longitude coordinate pair for an object. Once you have geo-coded an object you can perform searches by distance. Also you can return distance between objects in your queries. For example if all auto dealerships were geo-coded in your database, the user could enter his address and find results within a defined radius of that location.
The Celeriq engine allows you to perform standard aggregation functions on results sets such as sum, average, min, max, and count. This is a way of grouping records. For example, if all auto dealerships are grouped by state, it would create about 50 groups each with the records pertaining to the state. The defined aggregate fields could then be used to sum the price, average the mileage, etc with in each group.
All dimension data can be used to filter a result set with no customization at all. However there are times when non-dimension data needs to be used in filtering. For example, in an auto dealership scenario you would not make mileage a dimension because every car can potentially have different mileage. However users will still want to filter on mileage. In this case a custom filter can be applied on the mileage field that is more, less or equal to some value. Any number of combinations of dimension and custom filters can be concatenated to narrow a result set.