-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 But that requires that you haul an artificial construct around. On 11/24/06 12:38, Ben wrote: > It depends how it's going to be used. If you are going to reference this > table in other tables a lot and/or rarely care about what the name > actually is, then the two-column approach is going to be more efficient. > Numbers are smaller and easier to compare than strings. > > On Nov 24, 2006, at 6:54 AM, Tom Allison wrote: > >> I notice a lot of places where people use the approach of creating an >> index and a unique key like: >> >> CREATE TABLE foo ( >> idx SERIAL PRIMARY KEY, >> name varchar(32) UNIQUE NOT NULL >> ) >> >> instead of >> CREATE TABLE foo ( >> name varchar(32) PRIMARY KEY >> ) >> >> If the name is NEVER going to change, is there any advantage to doing >> this? >> If there are many-to-many reference tables (like name-to-friends) is >> this any different? >> >> I've seen this a lot, but I've always assumed that with the condition >> that 'name' would NEVER change, there was no advantage. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFZ0SIS9HxQb37XmcRAppYAJ9i5PpJ021FyQYQSgTo9Alv8CDNHgCg1Q4p nMmJ64MHVNfE91EZIsJNwts= =piIg -----END PGP SIGNATURE-----
