最近在設計一個戶外APP的數據庫,在外鍵設計上有點糾結,用仍是不用,考慮了再三,仍是不用,數據庫
那麼如何表之間的關聯了。只能在字段名上作文章了。
併發
好比在用戶表裏面的ID,最好寫成userId
高併發
與之關聯的相冊表裏面對應一個userId便可實現關聯spa
參考1:設計
表的關聯,只是一種邏輯概念,本並不須要進行物理上的「硬綁定」,並且你所指望的關聯,其實只是其數據上存在必定的聯繫而已,而這種聯繫其實是在設計之初就定義好的固有邏輯。
因此在業務代碼中實現的時候,只要按照設計之初的這種固有關聯邏輯來「存/取」數據便可,並不須要在數據庫層面進行「硬綁定」,由於在數據庫層面經過使用外鍵的方式進行「硬綁定」,會帶來不少額外的資源消耗來進行一致性和完整性校驗,即便不少時候咱們並不須要這個校驗。
因此通常不建議在數據庫中使用外鍵約束來保證數據的一致性和完整性。事務
參考2:資源
首先關於外鍵的做用與使用場景:
1.做用:經過數據庫提供的外鍵功能,進行數據完整性和一致性的維護,避免藉助外部力量維護;
2.使用場景:如果高併發大流量事務場景,使用外鍵可能容易形成死鎖,以及數據庫資源更快出現瓶頸,因此通常互聯網行業不建議使用,多使用再企業內部,好比ERP軟件,早期的MIS系統等
關於如何體現表與表之間的關聯性和如何維護數據完整性和一致性:
1.關聯性:那就是設計數據庫的時候,要讓全部人知道表與表之間的經過那個字段關聯起來,因此字段名稱命名上會作一些文章
2. 如何維護數據完整性和一致性:經過外部程序的力量,啓用事務的方式,好比:
START TRANSACTION;
UPDATE A SET co1=** ...;
UPDATE B SET A_co1=**...;
COMMIT;
註釋:假設場景 A表的col1變成某值以後,B表中的A_col1字段也必須修改成對應的值...軟件