0

So I have a data model that is a bit complex, and am trying to figure out how to model it.

I have Client. That Client belongs_to a Firm.

The Firm will have attributes like:

 - Firm Size (0.2, 0.4, 0.6, etc.)
 - Firm Type (Big, Small, Medium)
 - Priority Level (1, 2, 3, 4, 5 - from low to high)

A User has_many Clients.

That user needs to be able to edit the attributes of each firm:

E.g. add a new size to Firm Size (say 0.95).

So I was thinking of having a Firm model. Then also having a model for each of the attributes individually. So that way a user can add a new record to Firm Size, etc.

What I am a little confused about is the naming, and wouldn't that make the entry for each Firm look a bit weird, given foreign_ids and all? and how would I manipulate the data?

E.g. For a Firm, the record might look like this:

:name => "Firm A", :firm_size_id => 1, :firm_type_id => 2, :priority_level_id => 1

Then, when I want to find the size of a firm, I have to run a query like this:

Firm.find(1).firm_size.size

For FirmSize, what would I name the attribute: 'size'? If I do that, then I would do a Rails call like above of like this?:

FirmSize.find(1).size

That looks a little awkward. Or would I name the attribute name? FirmSize.find(1).name - but that doesn't fully capture what it is. It is the size of the firm, in this case.

The same applies to 'FirmType' and 'PriorityLevel', etc.

Then the other concern is once I want to do any calculations on these attributes, won't I have to do some weird gymnastics, like:

product = Firm.find(1).firmsize.size * Firm.find(2).firmsize.size

That seems a bit awkward...or is this normal?

Would love any help with clarifying the way I approach this.

Thanks!

marcamillion
  • 32,933
  • 55
  • 189
  • 380

1 Answers1

0

Why do you want to create separate models for Firm's size, type and priority level?
You should try to understand the purpose of having attributes/separate models for any information.

While looking at your question, a similar concept of XML sub-elements & attributes came to my mind. Though it's off-topic, but I believe this should get you more clarity into the whole thing:

Coming back to the question, I'd say you go on with making Firm as model and size, type etc.as attributes. Get this to implementation and then look back at your question again.

The primary reason why I say so is that I don't see FirmType, FirmSize & FirmPriorityLevel having more than a fixed set of values &
Your business logic won't be Firmtype or FirmSize centric in a huge way.

If latter is the case, I'd say re-think your strategy.
P.S. I'm not saying you are you are doing something wrong, just make sure you'r doing it in the best way.

Community
  • 1
  • 1
Jatin Ganhotra
  • 6,825
  • 6
  • 48
  • 71
  • I agree with you re: making sure I am doing it in the best way. That's why I asked this here...to get more clarity. The reason I have to have them separate is because FirmSize, FirmType, FirmPriorityLevel are NOT fixed values. The users should be able to create new 'sizes' easily, as well as new types and priority levels. Also, there should be a way to have two values. i.e. A FirmSize can be 'Big', but have a 'value' of 0.6, whereas small is 0.2. But when the user is choosing on the front-end, they just choose 'big' or 'small'. The same applies to the other attributes. Thoughts? – marcamillion Aug 28 '12 at 10:36
  • The scenario you are describing is TYPICAL. What's bothering you with this. Forget all this fuss about different sizes & types & users making them. Just go ahead and code the way I advised. – Jatin Ganhotra Aug 28 '12 at 10:40
  • Based on the context that you have provided, I believe what I have said is right. Still if there's something bothering you, mention a scenario and we can discuss that. – Jatin Ganhotra Aug 28 '12 at 10:42
  • You didn't answer my question though. If all I am storing is a 'size' attribute on the firm model...how do I handle those extra needs? – marcamillion Aug 28 '12 at 10:54
  • Oh, and the business logic IS FirmType & FirmSize centric in a huge way. It's a rating system I am building where these factors are at the heart of the application. Basically the firms will be ranked according to the scores, that the app calculates, based on the values assigned to each firm. So it's not a simple as something like - Firm Address, Firm Size = 20, etc. This is one of those apps where each of these things are at the core of the functionality of the app...if that makes any sense. Otherwise, I would have done it the way you are saying - but I see the flaw, hence my question :) – marcamillion Aug 28 '12 at 10:56
  • Still, I'd say go with `Firm` model. Think about if you make a `Firmsize` model, what would be it's attributes other than the foreign_key firm_id. If you come across any such attributes that would help you in implementing the app, then make a `Firmsize` model, else don't. – Jatin Ganhotra Aug 28 '12 at 15:39
  • Long answer short, think of what data should essentially go in a model and why(how you'll do CRUD on it based on your app) – Jatin Ganhotra Aug 28 '12 at 15:40
  • @marcamillion: What did you finally decide on? If it's my way, then please accept and upvote my solution. If it's something else, please explain it in an answer and accept that, so others can make sense of this question. – Jatin Ganhotra Aug 29 '12 at 17:49
  • I still haven't decided. I know it's not your way, because it doesn't fit the business domain rules - but I haven't figured out exactly what it will be....yet. Once I have an answer, I will be sure to update. – marcamillion Aug 30 '12 at 00:40