2012-11-25 68 views
1

數據庫正常化讓我非常緊張。假設我有一個場景來找出共同的朋友。而我使用的三個字段我的數據庫遵守數據庫規範化

conn_iduser_idfriend_id

USER_ID表示用戶的正常ID,和朋友id表示相同的,我只是想給每個相關用戶的朋友。

我現在輸入用戶ID,然後輸入朋友的ID,一個記錄每個

例如:

conn_id | USER_ID | friend_id

1 - US1 - US2

2 - US1 - US3

3 - US1 - US5

4 - US3 - US1

5 - US3 - US6

........................................等等

它如何不符合數據庫規範化?

編輯(澄清評論):

有人讓我疑惑的說,我有一個記錄與用戶1 - 用戶2。另一個記錄與user2 - user1:這不違反規範化,是嗎?

+0

不確定,一張有兩個FK的表大約可以得到標準化,但我有時會在像這樣的簡單表中省略PID列...也許他們反對呢? – Mitch

+0

那麼,如果沒有PID,列,至少用第一個正態表達式來做這個事情嗎? @Mitch – cipher

+1

另請參閱:http://dba.stackexchange.com/questions/10199/how-should-i-design-a-relationship-table-for-friendship – FoolishSeth

回答

1

常見的規範化違規行爲是,當行已由其中的某列或某列的列組合唯一標識時,該行的序列號正在粘合。當然,人們總是這樣做。有理由保持你的模式正常化,並有很多理由不是也這樣做。

在這裏看起來就是這種情況。如果重複條目(user_id,friend_id)沒有意義,那麼可以將該列組合用作主鍵。除非順序號本身具有實際意義,否則它可能與歸一化方面無關。

UPDATE

另一個你帶了下面要考慮的是重複記錄的可能性,例如(u1→u2)和(u2→u1)。這歸結爲友誼是否可交換的問題。

如果user2是user1的好友,那麼user1是否也是user2的好友?如果友誼是可交換的,那麼你會有重複的記錄。如果這就像一個社交應用程序,我會認爲情況並非如此,這些都不會是重複的記錄:它們代表兩個完全獨立的關係。

+0

我編輯了這篇文章。請看現在@FoolishSeth – cipher

+0

因此,如果我刪除conn_id,它是否符合至少1NF的形式? – cipher

+0

我很確定它已經是1NF了,沒有做任何改變。你爲什麼認爲它不在1NF? – FoolishSeth