How would one save the guest_id in a the party table?
I don't think one would. I can think up a few examples of how you might choose to model this. In all cases the guest_id would not be saved in the party table. If you have a simple one to many relationship on parties to guetss you might have two tables like:
guests (belongs_to_party, party_id goes here)
You could expand on this and say, guests might go to many parties and I want to track each guest individually without duplication when they go to many parties. In this case you might do:
parties (has_and_belongs_to_many guests)
guests_parties (party_id, guest_id, no id column, simple join table)
guests (has_and_belongs_to_many parties)
Now we can get even fancier and say, Id like to store with each maping of a guest to a party a rsvp message (like I'll be 30 mins late, or Im brinning steak for the grill...). We can't do this (or shouldn't) with a HABTM relationship, so we need to add a 3rd model.
parties (has_many party_guests)
party_guests (party_id, guest_id, rsvp, etc)
guests (has_many party_guests)
Now we can tack into the party_guests tables our rsvps and other such things. However, this is only a start. We might want to use other rails goodies to make this make more sense. Example, we might want to access the guest models without needing to load up the party_guests. We also might want to rename some of these relationships to something more natural-language-like.
parties (has_many rsvps, class_name PartyGuests
has_many guests through rsvps)
guests (has_many rsvps, class_name PartyGuests
has_many parties through rsvps
I am using sudo-code. You will want to look up the exact syntax, but this quick example will give you some ideas. As you can see, adding a guest id into the party table doesn't really work, but you have *lots* of choices on where to go with it. I recommend starting with something simple and refactoring only when you need a feature you don't have.