This really isn't a great table design since you're not actually gaining anything by splitting the information this way. The lookups are slower than on a single table using a straighforward SELECT query along the lines of "SELECT ipaddress WHERE name=?", but you haven't gained any additional flexibility since everything is bound to the name_id.,

If you really want to use ids to track this information a better schema would be:

create table names (
   name_id INT NOT NULL auto_increment,
   name_str VARCHAR(255)
   );

create table ipaddresses (
   ipaddress_id INT NOT NULL auto_increment,
   ipaddress_value VARCHAT(255)
   );

create table ip_names (
   name_id INT NOT NULL,
   ipaddress_id INT NOT NULL
   );
[download]

This gives you a lot more flexibility -- reverse look ups on virtual hosts, for instance, and allows for extensibility at a later date (associating machine-specific information with an IP address id, and domain specific information with the name id).

I would tend to agree with you, but you really only need the two tables if the assumption is a one to many relationship.

But assuming a many to many relationship your schema is nicer, and certainly if you expand the scope, having an id on both the ip address and name is a good thing (most probably a necessary thing).

One minor point though, you can still do reverse lookups on my schema:

$sql_statement = qq|select tbl_names.str_name
           from tbl_ipaddresses, tbl_names
           where tbl_ipaddresses.str_ipaddress = '201.2.23.2'
           and tbl_names.id_name = tbl_ipaddresses.id_name|;
       $sth = $dbh->prepare($sql_statement);
       $rv = $sth->execute;

       while (    ($str_name) = $sth->fetchrow_array ){
           # do whatever
       }
[download]

But thanks for pointing out a nicer way of doing it than I did.

Thanks,

EEjack