Forum: Ruby on Rails every table must have an id

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
16c22720606d0de83b528cb3acc384f3?d=identicon&s=25 Farooq (Guest)
on 2005-12-27 19:47
Hello,
 Not sure if this is implied in the documentation or something given:
does the RoR framework require "every table must have an id" ? If this
is the case, then what happened to the concept of normalization ?
Futher, if the tables have already been  build for an existing
appication ( without ID column in everytable ) , will the script /
generate work ?

Thanks
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 Francois Beausoleil (Guest)
on 2005-12-27 20:24
(Received via mailing list)
Hi !

2005/12/27, Farooq <farooqm@myway.com>:
>  Not sure if this is implied in the documentation or something given:
> does the RoR framework require "every table must have an id" ? If this
> is the case, then what happened to the concept of normalization ?
> Futher, if the tables have already been  build for an existing
> appication ( without ID column in everytable ) , will the script /
> generate work ?

Yes, all tables need an ID or equivalent column.  It need not be
called ID (see #set_primary_key
http://api.rubyonrails.com/classes/ActiveRecord/Ba...).

Normalization only ensures that the customer's address is not repeated
in more than one table.  That's why we use IDs to get at the
customer's record.

Never tried it myself, but script/generate scaffold should work with
your existing tables.  You will need to change the generated models to
set your primary key, though.

Hope that helps !
2dd904ec5981c31e7bb7a5743a53caf8?d=identicon&s=25 Bruce Balmer (brucebalmer)
on 2005-12-27 22:43
(Received via mailing list)
Yes. Every table must have an ID, but I believe you could call it
something else (mainly to assist with legacy tables).

Normalization has nothing to do with not having an ID column.
Normalization is a process the exists independent of the idea of a
column called ID. You could do it with a meaningful column like
social-insurance number.  However, meaningless ID columns are a wiser
choice.

if you don't have an id column then updates/edits won't work.

bruce
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2005-12-28 15:04
(Received via mailing list)
On Tue, Dec 27, 2005 at 02:21:49PM -0500, Francois Beausoleil wrote:
} Hi !
}
} 2005/12/27, Farooq <farooqm@myway.com>:
} >  Not sure if this is implied in the documentation or something
given:
} > does the RoR framework require "every table must have an id" ? If
this
} > is the case, then what happened to the concept of normalization ?
} > Futher, if the tables have already been  build for an existing
} > appication ( without ID column in everytable ) , will the script /
} > generate work ?
}
} Yes, all tables need an ID or equivalent column.  It need not be
} called ID (see #set_primary_key
} http://api.rubyonrails.com/classes/ActiveRecord/Ba...).
}
} Normalization only ensures that the customer's address is not repeated
} in more than one table.  That's why we use IDs to get at the
} customer's record.
}
} Never tried it myself, but script/generate scaffold should work with
} your existing tables.  You will need to change the generated models to
} set your primary key, though.

Is there support for multi-column keys? I have a situation in which the
most reasonable schema has a table with a two-column key: the pairing of
a
foreign key and an ordering value. It is a simple has_many situation,
and
there is no reason to interact with records of the model outside the
dependent has_many collection.

} Hope that helps !
} --
} Fran??ois Beausoleil
--Greg
821395fe70906c8290df7f18ac4ac6cf?d=identicon&s=25 Rick Olson (Guest)
on 2005-12-28 15:10
(Received via mailing list)
> Is there support for multi-column keys? I have a situation in which the
> most reasonable schema has a table with a two-column key: the pairing of a
> foreign key and an ordering value. It is a simple has_many situation, and
> there is no reason to interact with records of the model outside the
> dependent has_many collection.

Not really, but you can get around it.  I'd suggest using a normal
primary key anyway, it'll be a *LONG* time before you run out of IDs.

--
rick
http://techno-weenie.net
This topic is locked and can not be replied to.