My data model is using inheritance with Core Data, and I can think of 3 strategies to store this data into CloudKit Records.
In the model let stay that there is an abstract class Element, and two subclasses: A and B
CloudKit Strategy 1: create Record Type A and Record Type B. Each Record Type contains the parameters of both the base class and its associated subtype
CloudKit Strategy 2: create Record Type Element. Element contains all the parameters of Element, A, and B, plus a string indicating if the record is actually Type A or Type B
CloudKit strategy 3: create Record Type Element, Record Type A, and Record Type B. Each contains the same parameters as the model. Record Type A and Record Type B also have an additional Reference parameter to the parent Element
I would assume that Strategy 2 is the easiest to implement, but it'll take more space in the Cloud. Should I worry about the wasted space only if my app actually takes off and focus only on having an easy CloudKit model to maintain?
Is Strategy 3 overkill?
Copying all the fields multiple times in several Record Types seems a bit lame if I use Strategy 1. But is it what is usually done?
It probably depends on the actual size of the data model. The part of the DB that needs to be clouded has about 10 tables.
Which one is the best strategy?
I would probably go with Strategy 1, one record type per concrete class in your app, but if your types A and B are almost the same you could get away with Strategy 2.
If in the future you add more fields to your type B, under Strategy 2 you would have to add those fields to every record you have created for objects of type B or A, this feels less correct to me.
In terms of code complexity I doubt that using Strategy 1 would take you more effort or code than using Strategy 2.
Strategy 3 would likely take you more effort and code, and I don't see much benefit in it.