So, if Gyxi DB is fast, powerful, easy to learn, scalable, then “what is the catch”?

Firstly, I want to underline that it truly is all those things. And it is due to one major trade-off and that trade-off is “the catch”.

The views are powerful and flexible, but, and here it comes:

The views are not updated instantly!

After you change any of your base data and you want to query some of that data from a view, it takes a little while before they show up.

As a general rule of thumb, it takes a few seconds, very likely less than 10 seconds.

However, it does depend primarily on one thing and secondarily on a few other things.

Firstly, the main factor that determines how long time it takes before your view is updated is how many views you have for that type of data.

For example, if you have 30 views on a single type of data, that’s a lot and it will take longer before all the views are updated. However, the views are updated in parallel so even with 30 views it is very likely that all your data is in most cases updated in less than 10 seconds.

The views are updated AFTER you change your data. That means it is out of your hands.

So this is the big trade-off.

It doesn’t mean your end users need to wait a few seconds before they can work with data they just added. You determine the id of your data and the data is instantly available in your base database.

One common strategy is that you have data from a view in your user interface and now you add another piece of data. When you add the data, you simply keep it in your client side array when you save it in the database and allow the user to continue working with it.

If your code requires you to get data from the database to work with it, simply get it from the base data where it will always be available instantly.

So that’s the big catch. Your application developers have to be aware that there are a few seconds delay before data becomes available in views and in some cases they will have to take that into account while coding.

Gyxi DB is fast and affordable, but these are hygiene factors and they are unimportant unless Gyxi is also powerful and useful.

This is the role of Gyxi Views.

Saving one or more items in a database is relatively uncomplicated. It gets complicated when having to make complex queries to retrieve that data and that is also where using a database can become slow and thus useless.

That is why there are no queries in Gyxi DB. Instead there are only Views. For any query you want to make against your data in Gyxi DB, you have to define a view. This view will then be like a prepared query. It will contain the right data in the right order, organized in the right way, placed exactly how you are going to use it.

If the view doesn’t match what you want the solution is simple. Create another view.

You can create any view you want, but we did define some typical scenarios or “view types” which make it easy to understand how views work.

1. Basic Index

In a database, a basic index is when you choose a field in a table and make it fast and efficient to look up data based on that field.

2. Combined Index

Similar to a basic index, but combines multiple fields into a combined index.

3. Lookup

Uses one or more fields to be able to look up (with extreme efficiency) a single item.

4. Ordered

Define the order of the view based on a field, either ascending or descending. This can be combined with most other views.

5. History

This specialized view will contain a row for every change to your data. This is achieved by setting the partition key to the current partition+id and then the id is set to the timestamp of the change.

6. Partitions

You can find partitions in your data through the portal. However, if you need the partitions through your application, then you can make a view for this. Set the partitionKey to “null” and set the id to be the key that contains the partition.

However, if you need this table, it is likely you have a problem with your data structure. Consider contacting us for guidance instead of creating this view.

7. Search by Array

This view allows you to make any field, containing an array, searchable (again, with extreme efficiency and scalability).

For example, perhaps your items have a an array with one or more categories associated. This view will allow you to search based on those categories.

8. Full Text Search

Makes it possible to search based on the text in a single field on the item.

Saving an item that has a view based on full text search with the text in the preceding paragraph will cost 26 operations.

Looking up in a view with full text search is very efficient and only costs a single operation but saving new items to the view will require it to be indexed and that makes this view relatively expensive.

The good news is that Gyxi DB is very affordable so even if this view is relatively more expensive than other views, it is still far cheaper than alternatives.