Just working out my db schema before I start development and I got
stuck on my join tables. With the way most associations work in rails
already. Are join tables really needed? Rails will handle most of that
auto magically so won't building and maintaining these tables in the
application by hand be redundant?
Don't start by working out the db schema, start by defining the models
that map the objects you are modeling in the real world, then define
the associations between them. Whether you need hand crafted join
tables or not will then become clear.
Sorry I deleted my original post as I thought I had figured it out
well talking out loud.
Well Model defining and the db schema kinda go hand in hand. I guess
I'm really just defining the model, but doing it in mysql workbench
=) . I'm bad with pen & paper =P
I'd have to say though at this point I'm still having trouble deciding
if I would need my own join tables. For most of my tables I'm thinking
not. The more I think about I can't think of any situation I would
need a join table anymore but then I wonder if it's just ignorance
lol. Support tickets for example. A Ticket will have many updates.
I'll always find the ticket_updates via :through & :has_many. And if I
have a ticket_update I can always find the ticket because ticket_id
would be stored in the ticket_update. This is just a single example of
which I may or may not have done "correctly." But I really just can't
think of an instance that this system wouldn't work. Every db I've
made all relationships have worked out like that. I mean I could brake
that up into a join table but it seems like it would take more effort
to query the join table and get the results then to just do it like
mentioned above.
I'd have to say though at this point I'm still having trouble deciding
if I would need my own join tables. For most of my tables I'm thinking
not. The more I think about I can't think of any situation I would
need a join table anymore but then I wonder if it's just ignorance
lol. Support tickets for example. A Ticket will have many updates.
I'll always find the ticket_updates via :through & :has_many. And if I
have a ticket_update I can always find the ticket because ticket_id
would be stored in the ticket_update.
Imagine that your Support tickets system has ability to attach some
tags to ticket. How would you implement that?
Generally join tables are used when there is has_and_belongs_to_many
association.
One can look at has_many :through as a join table fat enough to become
a model itself.
Sorry I deleted my original post as I thought I had figured it out
well talking out loud.
Well Model defining and the db schema kinda go hand in hand. I guess
I'm really just defining the model, but doing it in mysql workbench
=) . I'm bad with pen & paper =P
I'd have to say though at this point I'm still having trouble deciding
if I would need my own join tables. For most of my tables I'm thinking
not. The more I think about I can't think of any situation I would
need a join table anymore but then I wonder if it's just ignorance
lol. Support tickets for example. A Ticket will have many updates.
I'll always find the ticket_updates via :through & :has_many. And if I
have a ticket_update I can always find the ticket because ticket_id
would be stored in the ticket_update.
That is what I mean by defining the models and associations first. If you have
ticket has_many updates
and
update belongs to ticket
then why would you need a ticket_updates table at all? If you have a
ticket then the updates are available via my_ticket.updates and if you
have an update then it's ticket is the_update.ticket.
I see what your saying. Maybe it was just the late night but I was
having a problem getting my head around it. Really the best time for a
join table is in a habtm relationship. Then it would be a good idea.
Like If something was taggable. Would be a good example of a need for
a join table.
Thanks for your replies. I hope it was just a momentary lapse on my
behalf cause I know I knew that before lol.