As part of the Kinvey mobile Backend as a Service, mBaaS we offer our appdata service, which is where your application can store all of its data. This data is likely in the form of application objects for your development platform, or JSON data if you’re just using our REST interface. Since an object can be thought of as a collection of properties (keys) that represent specific values, it makes sense to store this data on the backend as key-value pairs. With JSON data it’s the same, as JSON is key-value based.

When storing key-value pairs the natural choice of database technology is NoSQL, as these databases are very efficient at storing key-value pairs. Kinvey uses a NoSQL data store for our backend, which gives us incredible performance, but it does come with some tradeoffs. The biggest tradeoff is that, since there are no JOINs in NoSQL, there are no inherent relationships between your Kinvey Collections.

You can still efficiently model relationships within your data, with just a shift to NoSQL patterns for data modelling, such as embedding and linking. The first way, embedding, relies on Kinvey allowing you to store very complex data as values in the appdata service. Since our client libraries are built on our REST service, which stores JSON objects, we can represent one-to-many relationships by having an array of key-values as a value in our JSON data (in the client libraries this would be an NSArray of NSDictionarys or an Array of HashMaps). For example:

Note that this stores a copy of each entity that you refer to, so it’s probably best to use it for storing data that won’t change frequently.

The other basic way to model relationships with your data in Kinvey is called linking and uses the unique id field required by all entities that are saved to the appdata service. This is represented in the database by the property “_id”. If you save an entity to Kinvey and don’t define the value for “_id” we generate it for you. The client libraries both have ways of specifying which instance variable represents this id (In the iOS library you must include a map from an instance variable of type NSString to “_id”, in the Android library you override the “getIdField()” method). Using the “_id” field and our queries you can easily create relationships.


One-to-many Relationships

If you want to map a one-to-many relationship, let’s say between the “stories” collection and the “comments” collection (each story can have multiple comments), then just add a property in each comment entity called “storyId”. If we want to pull all comments for the story named “Dewey Defeats Truman” then we can use the following queries:

Many-to-many Relationships

To represent a many-to-many relationship in Kinvey we have several choices. For example, we could create a third collection to manage the relationship; however, this probably isn’t needed for most applications. Instead it’s probably easier to have several one-to-many models in a single collection. In other words, if your application maintains a table of patients, then to represent the many-to-many relationship of patients to doctors, have each patient store an array of “_id” values for the doctors they’ve seen.

Then to get all patients seen by a specific doctor use:

Using these simple techniques you can use familiar relational data modelling patterns in your Kinvey mobile Backend as a Service, mBaaS. If you’d like to see how to use this in an iOS app, check out the example below.