4

The timestamps of the votes in the data dump are all at time 00.00.00. Are the ids of the vote rows in chronological order? I mean, did the vote with id 1 arrive before the vote with id 2?

1

No, I don't think they are but it would need an SE developer to confirm. Here are my thoughts:

There are two things at play here:

  • The generation of the id's
  • Transactions to record events

The Id's are generated by the database engine used by Stack Exchange and that happens to be Sql Server. If I assume the Id's are generated by using an IDENTITY column the current implementation states Each new value is generated based on the current seed & increment. and Each new value for a particular transaction is different from other concurrent transactions on the table.. It doesn't state anything of the values being chronological for transactions that run concurrently but have different start times.

Posts are hardly ever locked for a single user. So anyone can take every available action for them on a single post and the system will take it. As opposed to money transfer/bank transactions it isn't that import in which order the exact events took place. And this might lead to an effect were the creationdate of higher ids are prior to events with lower ids.

You stated correctly that the Votes table doesn't record timestamps so instead let's look at the posthistory table at Meta Stack Exchange with a query that finds records where the creationdate and it's id are not chronological.

This is some result:

enter image description here

When visiting the timeline for Answers with external references;... you'll see near the bottom an edit event and an answer posted. Those two transactions were so close together their id's and recorded creationdate were no longer chronological. There are more case like that, even were it differs days but that was a migration case.

tl;dr;

Did the vote with id 1 arrive before the vote with id 2?

In a lot of cases, yes but there is no guarantee this is always true and sometimes this can be way-off. Depending on your use case ignore this fact or allow for a margin of error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .