Natural Base Data Structure

One of the most common difficulties we see in relation to database design in a document database is people trying to save base data in way that is highly optimized to the way the data is expected to be retrieved.

It is often an unsolvable problem and even if it seems solved, then data may be retrieved in a different way later and then the work is wasted.

One common example is people trying to save data and put a combined property under “partitionBy” when saving. For performance reasons, this is not supported and it is also rarely necessary.

Instead, save the data in the most natural way, thinking as a human being. Your people are part of a company, so partition them by company. Forget for now that you want to query by postalCode. The key is to save your data in a natural way and then trust the views and use the views to transform your data in the way that you want.

If you really want to combine partition keys in your base data

However, if you really want a combined partitionKey in your base data, simply combine it yourself.

Suppose your object looks like this:

{
   “userId”: 1,
   “postalCode”: 2500
   “companyName”: “Northwind”
}

And for some reason you really want to partition your base data by companyName AND by postalCode. That is probably a silly idea, but if you want to, simply create a new property in your base object with this data.

{
   “userId”: 1,
   “postalCode”: 2500
   “companyName”: “Northwind”,
   “companyNameAndPostalCode”: “Northwind+2500”
}

And then when you save the data, choose to partitionBy companyNameAndPostalCode.

Don’t do it

So, yes, you CAN save your base data in a combined partition key like this. But we would really like to know why you need to do this. So if you are thinking about doing this, please let us know at support@gyxi.com.