为什么要给数据库分层？

数据划分是解决数据混乱的关键。
2 01 8 年，某电商公司通过数据分层，将2 0张表的日志数据整合为3 张表，重复计算减少了6 0%。
ODS层存储原始数据，DW层分为DWD（明细）、DWM（中级）和DWS（宽板），APP层提供应用程序。
设计时先聚合后扩展表，减少5 0%的计算量。
记住，先创造，再收集。

服务器的三层模型将服务器端分成

上次我帮朋友修电脑时，他有一台运行Windows 7 的旧台式电脑。
他总是抱怨打开文件很慢，尤其是相册。
我一打开任务管理器，就有一个进程在后台运行。
这是一个旧程序的数据库同步，占用了近9 0%的CPU。
我关上它，打开相册，它就出现了。

这让我想起了软件层。
数据访问层就像一个后台进程，专门负责对数据库的读写，无论你在前台做什么。
业务逻辑层是中间层。
根据您单击的按钮或输入的指令，您将移动到数据访问层以获取数据，然后对其进行处理，例如按时间过滤和排序图像。
表现层是朋友看到的相册的界面。
单击它，将出现图像。

等一下，还有一件事。
上次我写一个直接以 JSON 形式流式传输数据库查询结果的小工具时，我直接使用 JavaScript 在前端绘制了界面。
当时觉得这样就挺好了，不用担心前端如何展示。
结果有一个顾客正在用手机看。
屏幕很小，一堆数据挤在一起。
我突然想到，这个时候业务逻辑层是不是应该添加判断，根据屏幕大小返回不同的数据结构呢？
这三层中，数据访问层一定要稳定，不能因为它处于最底层而忽视它的效率。
业务逻辑层必须灵活并且知道如何将数据更改到表示层。
表示层应该看起来不错并且易于用户使用。
但问题是：用户真的需要那么多数据吗？有时候，简单直接不是很好吗？

信息系统的三种框架

说白了，信息系统框架其实很简单，可以分为三个维度：组织视角、设计模式、技术层面。
先说最重要的，组织层面的整体参考框架，将系统分为战略系统、业务系统、应用系统和信息基础设施四个部分。
比如我们去年跑的项目，战略系统负责分析数据支持决策，业务系统处理生产、销售等核心流程，应用系统提供财务软件等具体功能，信息基础设施是整个系统的物理基础。

还有一点是，三层架构模型通过设计模式中的职责分离，提高了系统的可维护性和可扩展性。
表示层负责用户界面，业务逻辑层处理规则，数据访问层负责数据操作。
对于3 000个左右的项目，三层架构可以保证接口的改变不影响业务逻辑，数据存储方式的改变不影响上层功能。

还有另一个重要的细节。
从技术层面来看，核心组件框架分为基础设施层、软件配置层和资源管理/业务逻辑层。
基础设施层是硬件基础，软件配置层提供功能和安全保障，资源管理层/业务逻辑层负责数据管理和业务逻辑处理。

一开始我以为这些是独立的概念，后来发现它们是相互联系的，共同构成了一个完整的信息系统。
等等，那是另一回事了。
虽然这些框架很重要，但系统安全性是实际操作中容易忽视的地方。
这是一个容易陷入的陷阱。
我觉得在实际应用中还是值得尝试和更加关注系统安全的。
毕竟，没有安全性，框架再好也没用。