具有提交ID，用戶ID和提交順序的表的主鍵

我正在爲用戶可能提交數據的Web應用程序構建數據庫。每個數據都是唯一的，並且多個用戶可以提交相同的數據。具有提交ID，用戶ID和提交順序的表的主鍵

從應用程序的角度來看，瞭解用戶提交數據的順序非常重要。

我爲此專門製作了一張桌子。它有以下領域：

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

我的問題是，我應該使哪些屬性的主鍵？

SubmissionID和UserID將允許重複SubmissionOrder s對(SubmissionID, UserID)對。

SubmissionID和SubmissionOrder將允許同一用戶提交相同的東西兩次。

UserID和SubmissionOrder ......將大大限制用戶在什麼條件他可以提交:P

所有這三個將允許重複SubmissionOrder S代表不同UserID秒。

有沒有另一種解決方案，我不琢磨？

這個問題在應用程序級更好的解決了嗎？觸發器？

謝謝你的時間！

PS：一些技術細節，我懷疑你會發現有用：

的應用程序是用PHP
的數據庫sqlite3的

來源

2011-10-11 Francisco P.

我認爲你已經提出了這個問題太模糊，可能通過試圖忽略域的細節。模擬一些如此模糊的東西很困難（有數據，而且我需要它，而這些沒有幫助定義的列似乎並不適合我）。 –

@MarkBrackett - 對不起。你還需要知道些什麼？用戶提交一段數據。另一位用戶提交相同的數據。我需要知道用戶提交上述數據的順序。 –

在大多數SQL平臺上，事情發生的順序只是有點模糊。據我所知，沒有SQL平臺保證這兩個要求。

必須沒有關係。
之前提交的內容必須看起來像是早於提交的內容。

對於時間戳列，以前的提交看起來總是看起來像早於提交後的提交。但是，不管您的dbms時間戳的分辨率有多好，很容易有兩個具有相同時間戳值的「提交」。

使用序列號（或自動增加數字），不會有任何關係。但是，SQL平臺不能保證在序列號爲3的行之前提交了序列號爲2的行。這意味着，如果您同時記錄序列號和時間戳，則可能會發現行對即下的的序列號也有以後的時間戳。

但SQLite並不完全是SQL，所以它可能是這個通用規則的一個例外。

在SQLite中，任何寫入數據庫的進程locks the whole database。我認爲鎖定數據庫意味着你可以依靠rowid()暫時增加。

所以我認爲您正在查看{SubmissionID，UserID}的主鍵，其中rowid（）確定提交順序。但我可能是錯的。

來源

2011-10-11 22:26:33

運行在問候到您的具體問題：

是很重要的，從應用的角度來看，要知道在哪個用戶提交的數據

我認爲，爲了有2個備選方案比合並字段主鍵：

（1）創建一個額外的列 - 一個整數（自動增量）主鍵。

或

（2）創建的時間戳字段和保存的日期/時間的數據被輸入。

來源

2011-10-11 21:44:51

我正在與第二個 - 很滿意。 –

因此，您有提交的數據（SubmissionId？），您希望允許重複（以便其他用戶可以提交重複數據），但不能爲單個用戶重複。這就要求（SubmissionId，UserId）有一個唯一的約束。

您的下一個要求是您「知道用戶提交數據的順序」。目前還不清楚所有提交的是否屬實，或者只有提交有重複*的提交。解決一般情況下（所有提交）解決具體 - 所以我們會去。

由於這是一個排序問題，SQL沒有真正處理的事情，您需要添加一個屬性，它會給你絕對的排序。 2種標準選擇是自動增量或時間戳。我們將選擇一個自動增量，以便您不必擔心關係。我認爲SubmissionOrder是您的佔位符。由於我們使用了自動增量列，因此保證它是唯一的。所以，我們對（SubmissionOrder）有另一個唯一的約束。

這些獨特的約束現在是您的候選鍵。選擇一個作爲主鍵，併爲另一個使用唯一的約束。

*您對重複SubmissionOrder的評論會混淆問題 - 表明SubmissionOrder僅對SubmissionId唯一。假設你有應用程序邏輯來創建下一個SubmissionOrder，這是一個有效的（雖然稍微難一些）的選擇。然後，您的唯一約束將結束（SubmissionId，SubmissionOrder）。

來源

2011-10-12 03:22:37

具有提交ID，用戶ID和提交順序的表的主鍵

回答

相關問題