Re: FK -> non PK - bad design?

>> So you're arguing that we can know from context (it's in a column
in a normalized database) that it's a scalar, but you won't accept similar contextual info (it's in a table, which by definition represents a set) to
know that the set can contain more than one element, even if the set has a singular name? <<

1. From the stuff I see, assuming a normalized database is leap of faith <g>.
2. SQL can have both tables and columns with the same name; the syntax tells the compiler what to look for. When you go to a data dictionary, you have problems because you are out of context. Maybe we should have had one name space, but its too late now.
3. The other "religous argument" is how to write names (uppercase, lowercase, with underscores, etc.) and we have some research on that.