如果妳改變這個sql，它將影響另壹個業務。如果沒有必要，盡量保持表和業務的原子性，重疊太多，後續工作和邏輯增加妳會瘋掉。
我幫樓主找了壹些關於“設計原理”的資料，看能不能給我啟發(非數據庫)。
7種設計臭味1。僵硬:很難對系統進行更改，因為每個更改都會迫使系統的其他部分進行許多其他更改。
2.漏洞:對系統的更改會導致許多地方出現問題，而這些問題在概念上與系統的更改無關。
3.健壯性:很難解開系統，使其成為可以在其他系統中重用的組件。
4.粘性:做對的事比做錯的事更難。
5.復雜性(不必要):設計包含沒有直接好處的基礎設施。
6.可重復性(不必要):設計包含了壹個重復的結構，這個結構可以通過壹個抽象統壹起來。7.晦澀:難以閱讀和理解。沒有很好地表明意圖。
11原則-原則
-階級原則
1.單壹責任原則——單壹責任原則
就壹個階級而言，其變化的原因應該只有壹個。
(責任是“改變的原因”。)
2.開-關原則-開-關原則(OCP)
軟件實體(類、模塊、函數等。)應該是可擴展的，但不可修改的。
對擴張持開放態度，對變化持封閉態度。
關鍵是抽象，它清楚地將功能的壹般部分與實現細節分開。
開發人員應該只抽象出程序中經常變化的部分。
拒絕不成熟的抽象和抽象本身壹樣重要。)
3.裏希特替代原理-利斯科夫替代原理(LSP)
子類型必須能夠替換它們的子類。
4.依賴倒置原則(IoCP)或依賴註入原則-依賴倒置原則(DIP)
抽象不應該依賴於細節。細節應該取決於抽象。
(好萊塢原則:“不要打電話給我們，我們會打電話給妳”。
程序中的所有依賴都應該以抽象類和接口結束。
為接口而不是實現編程。
任何變量都不應該包含指向特定類的指針或引用。
任何類都不應從具體類派生。
任何方法都不應在其任何基類中重寫已實現的方法。)
5.接口隔離原理(ISP)
客戶不應該被迫依賴他們不使用的方法。
接口屬於客戶，而不屬於它所屬的類層次結構。
(多個面向用戶的界面比壹個通用界面要好。)
-包裝內聚性原則
6.重用發布等價原則(REP)
復用的粒度就是發布的粒度。
7.***與封閉原則相同(CCP)
對於同壹個類屬性的改變，包中的所有類都應該* * *關閉。
如果變更影響了包，
包中的所有類都將受到影響，
而不會對其他包產生任何影響。
8.***相同的重用原則(CRP)
包中的所有類都應該是* * *可重用的。
如果在包中重用壹個類，
然後妳需要重用包中的所有類。
彼此關系不密切的類不應該在同壹個包中。)
-包耦合原理
9.非循環依賴原理
包的依賴關系圖中不允許出現環。
10.穩定依賴原則
穩定的方向依靠它。
封裝系統高層設計的軟件(比如抽象類)應該放入壹個穩定的包中。
不穩定的包應該只包含可能改變的軟件(比如具體的類)。
11.穩定抽象原則(SAP)
包的抽象程度應該和它的穩定性壹致。
穩定的包也要抽象，不穩定的包也要抽象。