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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.