Home/ Questions/Q 6683137
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T04:47:10+00:00

I am building the database for a web application where users may submit data.

  • 0

I am building the database for a web application where users may submit data. Each datum is unique, and more than one user can submit the same datum.

It is important, from the application’s standpoint, to know the order in which users submitted the datum.

I have made a table exclusively for this purpose. It has the following fields:

SubmissionID
UserID
SubmissionOrder
... # and other non-important ones

My question is, which attributes should I make primary keys?

SubmissionID and UserID would allow for duplicate SubmissionOrders for a (SubmissionID, UserID) pair.

SubmissionID and SubmissionOrder would allow the same user to submit the same thing twice.

UserID and SubmissionOrder… would limit the user considerably in terms of what he can submit :P

All three would allow duplicate SubmissionOrders for different UserIDs.

Is there another solution which I am not pondering?

Is this problem better solved at the application level? With triggers?

Thank you for your time!

PS: Some technical details which I doubt you’ll find useful:

  • The application is written in PHP
  • The database runs on sqlite3
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The order in which things happen is just a little fuzzy on most SQL platforms. As far as I know, no SQL platform guarantees both these two requirements.

    • There must be no ties.
    • Earlier submissions must always look like they’re earlier than later submissions.

    With a timestamp column, earlier submissions always look like they’re earlier than later submissions. But it’s easily possible to have two “submissions” with the same timestamp value, no matter how fine the resolution of your dbms’s timestamp.

    With a serial number (or autoincrementing number), there will be no ties. But SQL platforms don’t guarantee that a row having serial number 2 committed before a row having serial number 3. That means that, if you record both a serial number and a timestamp, you’re liable to find pairs of rows where the row that has the lower serial number also has the later timestamp.

    But SQLite isn’t quite SQL, so it might be an exception to this general rule.

    In SQLite, any process that writes to the database locks the whole database. I think that locking the database means you can rely on rowid() to be temporally increasing.

    So I think you’re looking at a primary key of {SubmissionID, UserID}, where rowid() determines the submission order. But I could be wrong.

    • 0