我们公司使用 SQL Server 来托管所有应用程序数据已经有一段时间了。我们使用一种典型的设置,将数据从各种数据源加载到暂存区,然后为不同的数据集市提供其特定目的的数据(其中存储有定制的数据)。
然而,从我的角度来看,这会产生数据“孤岛”,它会重复大量数据,并且很难保持所有数据的同步。此外,随着解决方案数量的不断增长,“筒仓”数据集市的数量也成比例增长,因为需求总是略有不同,并且我们有明确的指示为每个解决方案使用单独的数据集市。
应用程序使用与数据集市的直接连接,然后使用和操作数据(根据需要)。
我最近对此进行了很多思考,目前正在进行一些其他举措来实现我们的后端现代化,因此我做了一些研究,我的想法是提出以下建议:
- 保持暂存区域不变(将不同来源的数据简单导入到一个数据集市)。每个源和相应的 SSIS 包都有一个架构来加载此数据。这一切都应该留下来。
- 为暂存区域内的每个解决方案创建一个架构。可以在此级别上管理访问权限,以确保应用程序使用者无法访问“导入架构”或其他架构,而只能访问属于他们有权访问的应用程序的架构。一旦实施第 5 点(API),应在连接到数据集市之前进行授权。
- 用新定义的模式中的物化(又名“索引”)视图替换当前加载数据集市的“筒仓”数据集市和相关 ETL 作业(SSIS 包)
- 将用于 CRUD 操作的任何表从以前的应用程序数据集市移至“暂存区域”数据集市中相应的新架构(需要重命名,因为它现在涵盖一个数据集市中的整个数据仓库)
- 实现一个简单的 API,该 API 具有对已定义视图的 GET 请求和对第 4 点中的表所需的 CRUD 操作的 POST 请求
当然,每个步骤对解决方案本身以及它们使用数据的位置都有很大的影响。此外,当然还需要大量的开发时间。但这暂时不是重点,这更像是一个普遍问题,这是否有意义或者如何在 SQL Server 上设置它。
我只是觉得我们围绕数据构建了太多内容,这也使得其他领域很难改进/加速后端流程。
非常感谢,祝本尼一切顺利