Design – Where to define view-specific data objects in Rails

Rails has, built-in, the concept of Single-Table Inheritance. Read up on it and use it, it's perfect for this situation.

In essence, what it does is allow you to have a type field in your table which literally defines the type (class name) of the object defined in the row. Fields that don't have matching attributes on objects of a particular type are nulled and ignored. In other words: it does everything that Emmad suggests for you.

It is such a fundamental part of the framework that if you have a field named Type, which isn't implementing STI, then you need to add some code to make sure the framework knows that.

One word of warning though: there is a danger with this technique of ending up with a table with dozens of fields which are only used by a few records. If this starts to happen, consider taking some of those fields out into separate tables. That is, you can still have a single main table, but if Spices have 20 fields not used by other types, you can store that in another table with a 1-to-1 relationship to the Spice object.

My gut tells me that you're correct to want to put some code into the Model. The fact of the matter is that while those are the functional/nonfunctional requirements on your application today - that could change. You could be required to implement a database on the next iteration of this project, or even worse the entire way you're storing data could get overhauled.

The fact of the matter is stuff changes. The better you modularize and abstract your code, the quicker you'll be able to adapt to change down the road. You'll also set yourself up for easier unit and integration testing, too. That's an important factor, because detecting problems before they become problems saves time and reputation.