is it possible you are describing a has-many relationship and not a
has-and-belongs-to-many relationship?
anyway, for a habtm relationship, i think the convention would be to
not hold any of the data about states in the address table. instead the
join table contains info about the addresses table and states table.
then rails knows what you want to do when you tell it to use an habtm
relationship.
class State < ActiveRecord::Base
set_primary_key "statecode"
has and belongs_to_many :addresses, :foreign_key => "statecode"
end
class Address < ActiveRecord::Base
has_and_belongs_to_many :states, :association_foreign_key => "statecode"
end
where your states table is:
statecode (PK)
name
and your join table, addresses_states, is
statecode
address_id
if you are designing from scratch, just use an id column in the states
table and do away with all the extra work above.
the argument is that any column that carries a meaning, no matter if
it's unique or not, should not be used as a primary key field. the id
column's only purpose is to uniquely identify that row and should
carry no meaning/purpose beyond that.