Ask A Question

Notifications

You’re not receiving notifications from this thread.

how to create and use different sub models of base data model

Vikas Sharma asked in General

I am an iOS developer developing my first rails app. I would like to have suggestion on what i am trying to build. I want to create a web portal for different type of service providers.
Any body can sign up as user with basic info like name, email, password, address, phone.
After sign up user have to add the service they can provide and want to list on web portal. User have to select service from predefined list of services. Like Chef, Dancer, Musician.
A user can add more than one service. After selection of the service they have to provide some more info about the service. Some of basic information like price, experience are common for all service type, but for particular service user have to provide different info like if user is a chef then what kind of cuisine he can cook. If he is a Musician what kind of instrument he can play. I like to get some help on structuring the database model for the project.

Here is what i came up with,

User (id, name, email, password, phone, address, serviceId)

BaseService (id, type, price, experience, references)

ChefService extend BaseService (cuisineType, dietaryType, maxPeopleAccommodate)

MusicianService extend BaseService (genreType, instrumentType, areYoyABand, noOfBandMember)

Please let me know if i am on wrong path and this is not the right way to implement it. I am confused about the different service type. How can i save it and get it back. What is the right way to implement it so in future i can add more service types and more attributes on specific service.

Reply

This a good question and is semi-complex so there are a ton of different approaches to it.

One of the ideas that's related to this (which isn't necessarily the right way to go) is Single Table Inheritance. It lets you define a singe "Service" table in your database and then have a "type" associated with it so that you could have ChefService, MusicianService, etc all stored in the same place. I would say this is a bad idea because you're going to have a lot of extra columns on the table that aren't associated with the service, but it's a step in thinking in the right direction.

There are a bunch of different ways you could do this. One option would be to create a bunch of different tables for these and just store them separately. Another would be to create a Service table, and have two other tables "RequiredFields" and "FieldAnswers". You could create the BaseService like normal, and then based upon the "type" column, you could reference the RequiredFields table and look up ones that match that type. You'd have a record for each like

RequiredField (service_type, name, format)

  • service_type: "chef", name: "cuisine", format: "string"
  • service_type: "chef", name: "dietary_type", format: "string"
  • service_type: "chef", name: "max_people", format: "integer"
  • service_type: "musician", name: "genre", format: "string"
  • service_type: "musician", name: "instrument", format: "string"
  • etc

And then this could generate a form dynamically based upon the fields and types. Then when they fill out the form, you can save their results into a FieldAnswers table that stores the RequiredField ID and the answer.

Another option would be to group all these into serialized hashes in a text field. It's somewhat limiting, but could also work.


Also this is where database like Mongo are a bit better suited because you can store a "Service" and have different types of attributes easily included. You don't have to define your data structure ahead of time, but it has plenty of other gotchas that you'll want to look into first. If you're down to learn all that, Mongo might be a good solution for you.

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 85,376+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.