First, you never have a foreign key on both sides of a relationship.
That makes no sense to a RDBMS.
Let's say, I have a "members" table that tools like this:
id | member_id | name |
and I have a "invitation" table that looks like this:
id | member_id | date |
has_one :invitation, :foreign_key => "member_id"
belongs_to :member, :foreign_key => "member_id"
Second, I would highly recommend renaming your "member_id" column in you
"members" table. Appending "_id" to a column means it is a foreign key
in Rails naming conventions. Use something like "member_number" or
"member_identifier." This is both a courtesy for other developers
looking at your model and for your own sanity later. I'm assuming this
value is a unique number generated by your code when creating a new
member. Not sure why the "id" column wouldn't work just as well. But,
hey, it's your design. In any case you "member_id" column is NOT a
foreign key. It is a "secondary" unique value but it's not a key field.
Third, You are breaking the First Normal Form (1NF) by storing a
member's name in a single field. Assuming this is a person their name is
composed of First Name and Last Name. 1NF says to separate separate data
elements into separate columns (no composite fields). This is not
absolute. It's possible your member names are companies or something. In
which case you would not have a composite field.
So, that leave us with the following design, when following Rails
id | member_number | first_name | last_name
id | member_id | date
class Member << ActiveRecord::Base
class Invitation << ActiveRecord::Base
No need to specify the foreign key since Rails conventions are being
This is also assuming that each member can only have one associated
invitation since it is describing a one-to-one association.