The links table has Links.LinkOwner. If you have a Username field, you can just rename that to LinkOwner. It maps the the Users.Username field. All the Links table needs is LinkOwner to tie it to the Users table. (That is if you require all add-links to register.)
The Link table has _less_ information in it, because it uses data-relationships to build them, and heads towards a more normalized database.
Contact_Name ---> Users.Name
and
Contact_Email ---> Users.Email
This was "redundant" information from the users records in flat-file links. It was also "useful" if you don't require user-registration.
With user registration, you create a "user" object, that lives in a table. That object has ties to other objects and tables, which in turn have ties to it.
For instance, Users.Username is the key that ties the links table to the User record. You can do a search for Links.Username to find all the links that belong to a user, or you can do a search for Users.Username to find the user who owns the link (ie: LinkOwner).
That way, the user record is added only once, and there is only ONE UNIQUE field that ties the links to the users.
Make sense?
Once you grasp the concept of data relationships you start to try to make all these little tables, and then you forge some compromise :) A totally normalilzed database is an ideal. For performance reasons, some compromises are made -- such as storing the single logo/graphic in the Links record. It's a performance enhancement that makes a _lot_ of sense in the current archetecture, but if that advances, it can be abstracted out.
note: Over time, database tables have become smaller, but have increased in number. We used to make really, really big tables... but now it's easier to make smaller ones, and relate them (computers are fast enough to do that in real time, RAM is cheap and plentiful, etc).
PUGDOGŪ PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ