Should I use Global ID's or find another solution to my Notification system?

So 开发者_开发百科I have nearly finished my notification system, and just before I am about to implement reCAPTCHA, I test what happens if I spam the notifications.

To give you some background on my notification system. I determine the newest content, by its timestamp. I retrieve the rows from the database ORDER BY timestamp. The timestamp value is an integer formatted to Unix Time. When notifications are shown, they are hyperlinks, that follow this URL format -

http://test.com/article/id

Where id is the id for the table, each time a new article is submitted, the id increments. I noticed after spamming my notifications, that the URL's of the spammed notifications are in reverse order. After further investigation, I find that if I spam quick enough, the timestamp variable is not accurate enough, and records multiple submissions with the same timestamp.

Since my website is low traffic now, and there aren't many submissions, this is currently not an issue, but if, a very small chance, but if a piece of content is submitted at the same time as another, the notifications will rank when they were submitted wrongly, a small, but annoying bug.

So I'm wondering what I should do. Should I fix the issue, or is this an extremely minute chance of this happening. Due to the implementation of reCAPTCHA, spamming is not an issue, but there is still a chance this could happen by accident.

I have come up with 3 possible solutions. My question is which would be the most efficient

1. Create a global id for all 4 types of content, which increments every time a comment, article or update is created.
2. Use a more accurate PHP time function, such as microtime
3. Add some sort of secondary ranking variable

Given that there can be multiple threads and even multiple nodes in a cluster inserting data in different tables there is always a possibility that any clock based value you use will get duplicated in multiple, or even the same, table.

So my first thought is to use a global id table. You could use a common content table with an auto-incrementing primary key that all other tables foreign key into and use that for ordering.

On the other hand, by the same logic, how well can you ensure some fixed order between submissions? It is quite possible that two submissions will be committed to the database in the reverse order of receiving at the server. The only way to solve that problem I think is to a have a global gatekeeper that all requests have to pass through. If you are using such a gatekeeper, that is also the best place to assign the ordering value.

All in all, I think you should not insist on complete ordering because it does not exist unless it is a highly ordering sensitive system such as Trading or Betting. Otherwise microsecond should be good enough, as long as the notification for a comment on a article does not come before the article itself.