I have a set of three tables, grandchild, parent and child - all was well.

But having found this set of tbales very difficult to integrate with the db, I have now realised I can't set up a PK/FK constraint. Some of the values in my (hoped_for) PK, must be null - unless I create imaginery values for them.

It seems my composite PK cannot have any column null even though, as a composite, the value is still unqiue.

Whats a guy meant to do :rolleyes: lol

Should I create dopey data - eg setting a specifically NULL value?should I resort to a surrogate key (oh pulleeeze lol),or can I just be happy with a unique key being set.

a thread title like "got my self in bother?" gives no clue as to what the thread is about, forcing people to actually open the thread to find out, and you can be sure that some percentage of potential repliers will not bother, whether purposefully, or because they simply missed it because they're scanning the list of thread titles looking for certain words like query, primary key, and so on

second, you neglected to point out ~why~ some of your columns need to be NULL, leaving the onus on the person reading your post to try to guess what's going on

helps?

IBazz
—
2011-04-04T22:03:08Z —
#3

oops. sorry. was very frustrated and forgot about making the title meaningful.

I think I have made progress by making the nulls sensible values. Just goes to show how when I think I have the db structured well, there is room for improvement.

bazz

r937
—
2011-04-04T22:23:43Z —
#4

unfortunately, "dopey" values (as you said earlier) don't usually mean anything, and can lead to more trouble than they're worth

e.g. "9999-12-31" as expiry date

what kind of "sensible" values did you settle on?

IBazz
—
2011-04-05T19:28:10Z —
#5

I don't know why I got so exasperated.

All it took was for me to split the data into an extra table so that those which FK'd were primary keys.