7月9日 19:00-21:30 阿裡雲開發者社群首場“Offer 5000”直播開啟！14位團隊技術大牛線上招人，更有《阿裡雲技術面試紅寶書》助你拿下Offer！點選下圖或連結馬上投遞履歷
1.一張基礎表dept，100張單據表用到了dept中的deptno，對于100張單據表都去設定外鍵參照dept表，對于中小型系統來講，在資料庫中表結構設定這種關聯關系，對開發有益；
如果資料量不大，所有正确的設計思路都是可以正常發揮的。所有可以使用的查詢，所有可以不進行費勁的操作（操作想怎麼簡化就怎麼簡化）。例如：最坑的設計：“程式設計語言+存儲過程”。
2.對大型系統ERP系統（比如用友、金蝶），每張表引入這種關聯關系，實在是太恐怖了，如果在更新的時候，在前台和業務層校驗它deptno代号的合法性之後，存入表中，這樣是不是會更好？
（1）系統1示例圖
（2）系統2示例圖
如上圖所示，這兩種方法在資料量小的情況下都是可以解決問題的。可能有人會問，這兩種方法的差別是什麼？
最大的差別在于系統的可控性上。
假如以一個商城為例：
初期發現，每天隻有三個訂單量，這個時候的資料吞吐量不大，怎麼設計都可以（使用以上兩種方法都可以，此時沒有差別）；
後來随着推廣力度加強，突然有一天訂單量爆滿，假設有1000W單，此時如果使用“系統2”過程操作實作，那麼系統一定會蹦，整個設計無法繼續進行下去。
也就是說單資料庫的開發隻能夠提供一種基礎的鍛煉，相當于開發經曆的第一層。随後需要考慮到資料表的性能，以及系統的拆分問題。
如果要進行資料表的拆分，那麼這些關聯關系無效，事務處理也将面臨很大挑戰，而這種拆庫拆表的操作就稱為庫表分離。
庫表分離有兩種拆分模式：水準拆分、垂直拆分（垂直水準拆分）。
水準拆分示例：假如訂單表的資料量很大，将這些訂單表拆分為十個資料庫的表，每個資料庫的表隻儲存10%的資料；
垂直拆分示例：将資料表由一張表拆分為多張表，比如說商品表，有商品名稱、單價等基礎資訊和其他相關屬性資訊，這些可以放在兩個資料庫裡，使用者從A資料庫讀基礎資訊，從B資料庫讀完整屬性；
垂直水準拆分示例：用商城系統來說，将其拆分成“使用者資料庫”、“訂單資料庫”和“庫存資料庫”，從“訂單資料庫”裡又水準拆分10個資料庫。
這個時候看起來這些問題都可以得到解決，但同時也需要知道另外一個問題：如果将系統分庫（将系統拆分為若幹個子系統的過程），那麼拆分後的子系統之間的溝通以及控制問題也就出現了。
有人會問，拆分到很多資料庫，查找的時候不友善怎麼辦呢？其實可以再引入一個給資料查的資料庫，如果做到這裡就表明要接觸到一些系統架構問題了，這些過程一定是幹了幾年之後才能得到的結論。
如何做一個厲害的架構？拿下月薪兩三萬的職位需要哪些技術水準？
更多分享，請大家繼續關注後續的面試疑難點解析～
更多專業知識，面試技巧就在面試一點通，持續更新中……
感謝浏覽～
本内容來源于
阿裡雲大學-Java面試技巧