SQL - standard way to show foriegn key

This is more of an opinion question, but does anyone use/know of a standard
way to ID field names that are foriegn keys?

for instance:

contentID -> ID for this table
siteID -> related to the site table
otherID -> related to the other table

I started using:

contentID
siteID_fk
otehrID_fk

but thought I'd see if there were other established ways to ID those.

-Darrel

The standard way? Set up a foreign key constraint and leave the field name
alone. In fact, some join commands (NATURAL JOIN or USING) depend on the
foreign key field having the same name as its primary key counterpart.
Naming consistency is the most important thing. Mangling a field name to
reflect data type, relationship, or anything beyond what the field holds is
usually frowned upon in the database world. Name your fields, then set up
your foreign key constraints and rely on them to enforce data integrity
instead of some kind of "reminder" naming system for the human operator.

The surest way to spot an amateur is to see tables named "tblUsers" and
other such nonsense. <-- wink means don't take offense because you did
ask for opinions.


"darrel" <notreal (AT) nowhere (DOT) com> wrote

This is more of an opinion question, but does anyone use/know of a
standard way to ID field names that are foriegn keys?

for instance:

contentID -> ID for this table
siteID -> related to the site table
otherID -> related to the other table

I started using:

contentID
siteID_fk
otehrID_fk

but thought I'd see if there were other established ways to ID those.

-Darrel

The standard way? Set up a foreign key constraint and leave the field
name alone.

Ah. That would likely be the best way. Damn...I need to be working with a
better DB admin. ;o)

The surest way to spot an amateur is to see tables named "tblUsers" and
other such nonsense. <-- wink means don't take offense because you did
ask for opinions.

Ha!

Yes, well, off to google 'foriegn key constraints in MS SQL'

Thanks!

-Darrel

What version? In 2000, in Enterprise Manager, use the 'table and index
properties' button to set up relationships (aka foreign key constraints).
In 7.0, use the Database Diagrams section of Enterprise Manager. The
diagram will actually create the relationships you set up when you create
it. It's not as quick as the relationship tab added to 2000, but it gets
the job done.

You can always fall back on issuing T-SQL commands directly, but where's the
fun in that?