Re: OT: defining DB fields - working towards consistancy...

The traditional way of doing such things is to make a table that contains all the domains, another with all the ip addresses, and tables like vhost refer to the tables with the domains and ip addresses using foreign keys. That way, all your domains have the same type, and so have your ip addresses. Furthermore, it enables you to do queries targetted at domains or ip addresses, so it's easy to find a maximum length.

You are trying to apply structured programming techniques on relational databases. That's not going to work - you need to apply relational techniques. Apply the right tools in each domain.

Abigail

Comment on Re: OT: defining DB fields - working towards consistancy...

Replies are listed 'Best First'.
Re: Re: OT: defining DB fields - working towards consistancy... by cLive ;-) (Prior) on Jul 15, 2003 at 09:03 UTC
Ahhh, the ideal world :) cLive ;-)	[reply]
Re: Re: OT: defining DB fields - working towards consistancy... by rir (Vicar) on Jul 15, 2003 at 17:58 UTC
Normalization is good, but it does not eliminate the usefulness of data typing whether that typing is weak aliasing or more real. Both are worth pursuit. I don't know what MySQL provides as support for user defined types. I don't believe that any such support will be standard SQL.	[reply]
Re: Re: OT: defining DB fields - working towards consistancy... by herveus (Prior) on Jul 16, 2003 at 11:16 UTC
Howdy! Abigail-II wrote: The traditional way of doing such things is to make a table that contains all the domains... On the other hand, it may be the case that the tables are appropriately normalized (ignoring the physical data types) but the implementation was done with less care than one might like... yours, Michael	[reply]
Re: OT: defining DB fields - working towards consistancy... by Abigail-II (Bishop) on Jul 16, 2003 at 11:22 UTC
Uhm, no. That would be impossible in any database I know of. If the tables were appropriately normalized there would be exactly one column, in exactly one table that hold the domains. I don't any database were a column can have more than one type, and if there is one, I don't see how you can manage to define multiple types with "less care". Abigail	[reply]