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).
I think a lot of this comes down to what appears to be a simple misunderstanding.
Avoid - in this context means that where it does not make sense (for performance, readability, etc reasons) then don't follow the guide. Follow it where possible and be mindful of when you deviate that you're adding to tech debt.
Putting the comma before doesn't actually make commenting out columns easier - it just moves the problem to the other end of the list. Just try commenting out the first column in your SQL and you'll see what I mean.
I am totally lost when it comes to your comments on the second item. It seems you're trying to say that surrogate keys are easier to find or perhaps guess.
The indexes set out against a table can generally be accessed with a query making it very easy to work out what existing index suits your use case best.
Try - in this context means where it doesn't make sense (for performance, readability, etc reasons) then don't follow the guide. Follow it where possible and be mindful of when you deviate that you're adding to tech debt.
This is a pretty commonly asked question. The answer is two fold:
1. putting the comma before doesn't actually make commenting out columns easier - it just moves the problem to the other end of the list. Just try commenting out `first_name` in your example and you'll see what I mean.
2. because normal convention would be for the comma to come immediately after an item in written English.
This is an interesting idea. I will give it some thought as others have also suggested similar. Perhaps the guide could be relaxed a little to allow singular names.
Someone mentioned that tables can be considered like types - another interesting thought - in which case singular makes sense.
On the other hand it is a collection of something and therefore the collective term applies equally well.
When modelling data it should be the primary concern and not an ORM. Different applications will need access to the same information. ORMs are application specific and therefore should not determine how data is structured.
As for the non-English speakers finding the collective difficult; I can see that. I have not specifically considered their needs whilst compiling the guide. In the case of `flora` I am guessing you're thinking `plant`?
Amusing example however as you'll know following a style guide doesn't preclude one from using their own intelligence to choose sensible options rather than delving into the absurd.
I think I do a reasonable job of making that clear with the introductory paragraph, but yes it is something that cannot be understated. They are just three little things that do not constitute a complete security policy.
Junction looks like an interesting library for XMPP and Node.js.
It might also interest Node.js developers to know that this article was written as part of a tutorial on writing a Google Chat bot with Node.js. To see part one of the article please see the following Hacker News post: http://news.ycombinator.com/item?id=5175913
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).