What do you think it the neatest way of modelling 'zero-or-one to many' relationships, using a nullable foreign key or an association table?

Example: a project can have one manager assigned to it, or be unassigned.

[Project Mgr] 0..1 <------ 0..n [Project]

An association table is a bit of an overkill, but a nullable FK 'smells' a bit wrong, so I'd like to hear your opinions.

Nullable FK

pootle flump ur codings are working excelent.

Nullable FK.

Nullable FK.

-PatP

oh, all right... nullable FK

I would do it like this:

(which may be what you mean by an "association table").

If a project doesn't have a project manager then it doesn't need a project manager Id - much less a null Id. Only add nulls into a schema where there is some good reason for doing so. And it pays to be doubly cautious when considering nullable foreign keys because they have significant disadvantages.

okay, provided that i get to decide what good means

o rly?

significant how, if i may ask?

Nice to see that there's a consensus that nullable FKs are ok to use. A nullable FK it is, then!

I could have told you before people started responding that everyone bar one would have recommended that.

Also, I was tempted to say so initially but left it, but smell is not ordinarily a recognised stage in database design. Make whatever decisions you believe you can justify but justify them with reason. I am sure it is a small olfactory step to thinking that shoving an autonumber on to a table smells like normalisation.

pootle flump ur codings are working excelent.

Certainly if you want to make design decisions based on acclaimation on DBFORUMS. Even though I disagreed I wouldn't have wanted you to follow my example just because you read it here. Even less so if it happened to be the majority view. A million people are always wrong.

What I would suggest is that you study some decent books on database design and make sure you understand what are the potential advantages and disadvantages of nulls. Then you'll have more information with which to make up your own mind.

Association table ONLY, very rarely you'd use a "nullable" FK. I usually use them after the fourth Heineken.

Dave - I know most of the disadvantages of NULLs. With the exception of RDBMSs that stick to the ISO SQL standard where it comes to NULLable composite foreign keys (courtesy of you) I don't know of any NULL issues that are specific to foreign keys.
Care to enlighten?
In case it is relevant, the longer I work in the field the more and more dissatisfied I am becoming with NULLs. I'm not yet at the point that I would eliminate them from my every schema but I am moving in that direction.

pootle flump ur codings are working excelent.

Still waiting for a good reason for NOT using a NFK (outside of Happy Hour).

so am i, and i asked before you did

One reason for not using NULL-able Foreign Keys is that they force you to use outer joins in order to get correct answers, and to cope with the results of unmatched keys (many more NULL values) that those joins imply. This is a complete "straw man" in my mind, it is a factually correct but practically irrelevant point to me.

A better reason in my mind is that Foreign Keys imply a relationship. I usually track many details about a relationship like when it began, when it ended, etc. When I model things that have relationships, I normally treat the relationship itself as a "thing" to be modeled because that fits well with my view of my environment.

I see my environment as a rich and varied place. I'm rarely willing to compromise and represent things very simply in order to make the code very simple because that has never worked to my benefit. I always end up coming back and implementing most if not not more than I originally imagined, and then I have to deal with the "lost data" and the complexity of a system/schema upgrade on what is often a critically important system... This just is bad business to me.

-PatP