3 回答

TA貢獻(xiàn)1895條經(jīng)驗(yàn) 獲得超7個(gè)贊
您不能并且有充分的理由。請(qǐng)參閱KM評(píng)論。
我說您可以做的一件事是有兩個(gè)表,其中一個(gè)表包含匿名數(shù)據(jù),另一個(gè)表在真實(shí)用戶登錄后存儲(chǔ)真實(shí)用戶數(shù)據(jù)。
或者您可以(未經(jīng)測試或由我完成)具有這種表布局:
---Customers----
AutoNumber PK <- This links to all other tables in your database, and does NOT change.
CustomerID <- This can change.
CustomerType <- Anonymous or logged in.
當(dāng)他們登錄時(shí),將CustomerType和CustomerID更改為所需的名稱。
因此,您的查詢可能如下所示:
Dim customer As Customer = (From c In db.Customer _
Where c.CustomerID = {Some temp ID} _
AndAlso c. CustomerType = "Anonymous").FirstOrDefault
// After user logs in.
customer.CustomerID = {Make a new user ID here}
customer.CustomerType = "LoggedIn" {or what ever}
db.SaveChanges()
請(qǐng)注意,自動(dòng)編號(hào)主鍵永遠(yuǎn)不會(huì)更改。這樣一來,您與客戶表有關(guān)系的任何表仍然可以使用,而不必對(duì)主鍵進(jìn)行級(jí)聯(lián)更新(這就像用鉛筆刺中眼睛一樣)。

TA貢獻(xiàn)2037條經(jīng)驗(yàn) 獲得超6個(gè)贊
如果在任何時(shí)候都可能只有一個(gè)數(shù)據(jù)庫上下文實(shí)例,那么修改pk不會(huì)是一個(gè)問題。但是每個(gè)上下文實(shí)例都維護(hù)自己的緩存,并且可以緩存要修改的記錄。
EF與數(shù)據(jù)庫的交互使用pk(來自上下文緩存)來標(biāo)識(shí)它們正在查詢的記錄。如果上下文對(duì)象可以更新持久性密鑰,則其他上下文對(duì)象用來標(biāo)識(shí)該記錄的信息將立即且永久錯(cuò)誤。
簡而言之,如果更新主鍵,則可能在上下文的所有其他實(shí)例中使緩存無效,這將從根本上破壞EF。這是更新pk不好的主要原因之一。
- 3 回答
- 0 關(guān)注
- 684 瀏覽
添加回答
舉報(bào)