Treffynnon

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).

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)

Have you read Celko's book? If not I suggest you do. As the guide states at the very top that is where you'll find the detail you're after.

This doesn't solve the problem at hand either unfortunately. You'll still have a hanging comma in front of `last_name`:

  SELECT 
      -- first_name
       , last_name
       , email_address
    FROM users

  SELECT
       , last_name
       , email_address
    FROM users

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.

Thinking multi-column indexes here.

Basically this is the answer - besides that bit about acquiescing to the demands of an ORM.

This seems to be a simple misunderstanding.

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.

No, actually the collective of player isn't team in this case.

Not all players will be on the same team, but they still participate in the league so I disagree with this example terminology shift.

You would end up with a slightly more generalised naming like this in my opinion:

- athletes - teams - leagues

In this particular case there are no suitable collective terms.

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.

Perhaps because it was not built for the purpose of producing shot...

Have you seen Wes Mason's PHP Weekly newsletter: http://phpweekly.info? Is this intended as a replacement?

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.

I have updated the article to reflect that this was not a very recent addition.

Wikipedia may say 2005 but it did not make the draft status that the article refers to until June 2009, which we can all agree is a lot more recent.

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

The feature is still draft and only made version 1 in June 2009 (http://xmpp.org/extensions/xep-0166.html). I don't actually track changes in XMPP so I am open to correction on this point.

Around the time I actually wrote the article (many months before it was originally published in .net magazine) there had just been a libjingle release and I was told at the time it was a new thing to have this available to 3rd party developers.

The article was originally written as separate article to appear alongside the main article I wrote for .net Magazine.

The main article is about creating a Google Talk bot with Node.js so if you want to create something with XMPP then please have a read through of that article: http://news.ycombinator.com/item?id=5175913

Also when I submitted this article to Hacker News I entitled it "A short history of XMPP and Jabber" so I am not sure how or when it got renamed.

The current FP #1 article is from 2004 although amid the hilarity I missed the date.