Well that's good seeing as though I wrote the guide in the first place.

An illustration in bad pseudocode:

 PRIMARY KEY (account_number, transaction_date)

> Well that's good seeing as though I wrote the guide in the first place.

Apologies, I didn't realise. That was crass of me.

But could you explain what you mean by unique in some degree? Surely in the example you give the key is just unique, with no further qualification?

OK, so I think this might be a language/understanding difference here - perhaps what I have written isn't clear enough - not sure. The statement to some degree, in my opinion, doesn't imply that the key isn't actually unique. It still means unique.

What I meant is that if you don't have a unique column to make, say, a primary key with then you need to make it unique by adding (an)other column(s) to it in the key definition. Each additional column being a degree of difference/separation in my mind as I was writing it.

I hope that explanation makes sense and doesn't confuse the issue further.

I'd like to get your feedback on what you think it could say to make this clearer - I want to convey:

a. it must be unique.

b. you can have multi-column keys (some users - especially those tied to an ORM - don't actually know that you can do this).