I'm working on a system which manages inventory in a warehouse setting. All of the inventory items share some common traits, such as name, description, photo etc... However, there are about 6 very different types of objects in this inventory. The inventory consists of services, equipment, consumables etc... All of this data is stored in Parse.
My instinct here is to create various subclasses to represent each type of inventory item and store it's related properties. Natively in iOS, this works great. I am, however, struggling to wrap my head around how to approach this on the backend.
All of my custom inventory classes inherit from PFObject and it seems like I should be using different
ParseClassNames for each object. This would be nice and clean and human-readable on the backend, but it creates some limitations. For example, I can't use
PFQueryTableViewController to display a list of all inventory because it would require a separate query for each class and
PFQueryTableViewController only accepts a single query.
What are the pros and cons of both pooling all these inventory subclasses into a single Parse class (using the same
ParseClassName string) versus creating totally separate
ParseClassNames for each of my subclasses (and thus storing them in separate tables).
Is there any other approach that would work for this scenario?