[英]data modelling, how many fk should i use?
假設您有以下架構。
用戶有多個部門,(fk user_Id)
每個部門都有許多辦事處(fk department_Id)
每個辦公室HV有很多事務(遇到s)(fk office_id)
現在的問題是,如果我想得到一個用戶的所有消息,我將需要搜索該用戶所在部門的辦公室中的所有小包。
您認為很多聯接嗎?
但是,如果我在遇到表中包括樹的所有外鍵? 然后我可以select * from encounters where user_I'd = X
但是,這使我的表看起來很丑陋,並且包含許多我想要的父級重復數據!
所以我的問題是,在這種情況下最佳實踐是什么? 更多fk或更少,並使用聯接?
設計表時,通常不會做任何冗余,而是將多次連接的復雜性保留在服務器端代碼的服務層內。 當您以后要更改設計時,它可以提供更大的靈活性。
那可能是宗教問題,而不是純粹的邏輯問題,因此您可能需要更多類似的答案來決定。
首先,分層結構確實沒有那么糟糕。 如果要進行很多查詢,以獲取與特定用戶相關的所有遭遇,請創建視圖。 可能看起來像:
create view Encounters as
select
Transactions.Id as TransactionId,
Offices.Id as OfficeId,
Departments.Id as DepartmentId,
Users.Id as UserId
-- other fields
from Transactions
join Offices on Transactions.OfficeId = Offices.Id
join Departments on Offices.DepartmentId = Departments.Id
join Users on Departments.UserId = Users.Id
這樣,您可以對任何Id字段執行查詢,而不必每次都重新創建聯接,請select * from Encounters where UserId = 12345
我自己不會打三個電話。 知道非正規化遇到表的好處是否超過成本的唯一方法是查看您是否遇到問題並通過非正規化解決。 我認為現在就做出決定還為時過早。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.