我有两个业务,是写在一个SQL中还是写两个SQL处理
发布网友
发布时间：2022-04-10 01:56
共1个回答
热心网友
时间：2022-04-10 03:26
你改这个sql就会影响到另一个业务。如非必要，尽量保持表、业务的原子性，交叉太多，随着后续工作和逻辑递增你会疯掉的。
我帮楼主找了点关于《设计原则》的资料，看看能否对有点启发（非数据库方面的）
7种设计坏味道 1.僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
2.脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
3.牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
4.粘滞性： 做正确的事情比做错误的事情要困难。
5.复杂性(不必要的)： 设计中包含有不具任何直接好处的基础结构。
6.重复性(不必要的)： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。 7.晦涩性： 很难阅读、理解。没有很好地表现出意图。
11种原则 - Principle
----类原则
1.单一职责原则 - Single Responsibility Principle(SRP)
就一个类而言，应该仅有一个引起它变化的原因。
(职责即为“变化的原因”。)
2.开放-封闭原则 - Open Close Principle(OCP)
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。
(对于扩展是开放的,对于更改是封闭的.
关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来.
开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象.
拒绝不成熟的抽象和抽象本身一样重要. )
3.里氏替换原则 - Liskov Substitution Principle(LSP)
子类型(subclass)必须能够替换掉它们的基类型(superclass)。
4.依赖倒置原则(IoCP) 或 依赖注入原则 - Dependence Inversion Principle(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
(Hollywood原则: "Don't call us, we'll call you".
程序中所有的依赖关系都应该终止于抽象类和接口。
针对接口而非实现编程。
任何变量都不应该持有一个指向具体类的指针或引用。
任何类都不应该从具体类派生。
任何方法都不应该覆写他的任何基类中的已经实现了的方法。)
5.接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。
接口属于客户，不属于它所在的类层次结构。
(多个面向特定用户的接口胜于一个通用接口。)
----包内聚原则
6.重用发布等价原则(REP)
重用的粒度就是发布的粒度。
7.共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。
一个变化若对一个包产生影响，
则将对该包中的所有类产生影响，
而对于其他的包不造成任何影响。
8.共同重用原则(CRP)
一个包中的所有类应该是共同重用的。
如果重用了包中的一个类，
那么就要重用包中的所有类。
(相互之间没有紧密联系的类不应该在同一个包中。)
----包耦合原则
9.无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
10.稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
应该把封装系统高层设计的软件（比如抽象类）放进稳定的包中，
不稳定的包中应该只包含那些很可能会改变的软件（比如具体类）。
11.稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
(一个稳定的包应该也是抽象的，一个不稳定的包应该是抽象的. )
