On Tue, Dec 16, 2008 at 4:59 AM, MarkMT <[email protected]> wrote:
>
>
> On Dec 14, 11:10 pm, "Nicholas Orr" <[email protected]> wrote:
>> On Sat, Dec 13, 2008 at 5:40 AM, Dan Kubb (dkubb) <[email protected]> wrote:
>>
>>
>>
>> > Hi Nicholas,
>>
>> >> I have this data >http://files.nicholasorr.com/data.html
>>
>> > I don't mean to be rude, but looking at this data, this looks
>> > *exactly* like a homework assignment.  I mean, the contrived data
>> > combined with the answers it's expected to satisfy, there's just no
>> > question in my mind.  If this is homework, you're probably better off
>> > admitting that up-front.
>>
>> The contrived data is just simplified.
>> It isn't homework - I get how it appears like homework.
>>
>>
>>
>> > Also you're unlikely to find help in an online forum for such tasks
>> > unless you provide all the code examples you've done, including the
>> > exact code that didn't work.  You should also try to explain why you
>> > thought each code example should have worked, and ask for specific
>> > help to explain where you went wrong.  If you post your code on
>> > gist.github.com or pastie.org and provide the link in future emails
>> > you'll have better results.
>>
>> >> I'm not looking for complete models here, just the relationships.
>> >> I've done the models all ready
>> >> I also did the relationships that I thought would work.
>> >> They don't work.
>>
>> > As I mentioned to you in IRC, you're best approach to data modeling is
>> > to sit down with a pencil and paper and draw out the diagrams of how
>> > things relate.  Writing the model code before figuring out the proper
>> > relations between the entities is likely the backwards approach when
>> > you're just learning.  In fact I almost never write code without first
>> > sketching a rough outline of my entities, how they relate and the key
>> > data each entity contains.
>>
>> Yeap. I tried this one on and came up with something. I've implemented
>> most of it.
>>
>> http://gist.github.com/35835
>>
>> What I'm having trouble with now is:
>>
>> how to get n rates associated with a rate_plan & a productlender
>>
>> I think I need another table that is just a group of rates - but that
>> is what the rate_plan table is suppose to be..
>>
>> As a "user"  you have a rate_plan. In this rate_plan is a product who
>> has a lender who has some rates/rate_modifiers.
>> There is one product with multiple lenders and the lender rates are
>> different to each other.
>>
>> As you can see the code is a lot more detailed then the simplification
>> I gave earlier and all I'm really looking for here is guidance on how
>> to link the different models together - thanks :)
>
> Nicholas, the way I'm reading your problem description, it sounds as
> if a product lender can belong to multiple rate plans and each rate
> plan has multiple product lenders, i.e. these two things have a many
> to many relationship. Also, a specific rate and rate modifier seem to
> be associated with each particular combination of rate plan and
> product lender, not with a rate plan as indicated in your current
> design.

Yes this is a great breakdown of what I want to achieve. Only bit I
would add is that there will always be more then one
rate/rate_modifier per product, lender & rate_plan combo. In order to
select the correct rate the user needs a rate_plan, that rate_plan
needs to be associated with a product,lender,rate,rate_modifier. Then
this question is asked
"Give me the rate & lender for product x on rate_plan y where
finance_amount_high >= theAmount and finance_amount_low <= theAmount"

> If this is the case, I would suggest a 'has n :through
> => :some_through_resource' relationship between ProductLender and
> RatePlan. Conceivably, the rate and rate modifier properties could
> actually be attributes of the through model, but otherwise each could
> have a one to one or one to many relationship with the through model,
> depending on your requirements. I suspect the latter.
>
> Mark.

So with this I'd collapse the rate & rate_modifier model into one and
this new model would become the through resource between productlender
and rate_plan.

That sounds logical. Thanks I'll give that a shot :)

(for the record this isn't so much "complex" as much, it just isn't
"normal", normal being post has comments. I'm dealing with company at
one end of the chain going through user,rate_plan,product,lender and
getting a rate at the other end)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to