já usamos o SQL Server há algum tempo em nossa empresa para hospedar todos os dados do aplicativo. Usamos uma configuração típica com dados sendo carregados de várias fontes de dados em uma Staging Area, que posteriormente alimenta diferentes datamarts para seus fins específicos (com dados personalizados armazenados lá).
Porém, do meu ponto de vista, isso gera "silos" de dados, que duplicam muitos dados e dificultam a manutenção de todos de alguma forma síncronos. Além disso, como o número de soluções cresce constantemente, o número de datamarts "silos" cresce proporcionalmente, já que os requisitos são sempre ligeiramente diferentes e temos instruções claras para usar datamarts separados para cada solução.
Os aplicativos usam conexões diretas com os datamarts para consumir e manipular os dados (conforme necessário).
Estava pensando muito sobre isso recentemente e há algumas outras iniciativas em andamento no momento para modernizar nosso backend, então fiz algumas pesquisas e minha ideia é propor o seguinte:
- manter a área de preparação como está (importação simples de dados de diferentes fontes para um datamart). Há um esquema para cada origem e pacotes SSIS correspondentes para carregar esses dados. Tudo isso deveria ficar.
- crie um esquema para cada solução na área de preparação. Os direitos de acesso podem ser gerenciados nesse nível para garantir que os consumidores do aplicativo não possam acessar os "esquemas de importação" ou outros, mas apenas aqueles que pertencem aos aplicativos aos quais eles têm acesso. Assim que o ponto 5 (API) for implementado, a autorização deverá ocorrer ali antes da conexão ao datamart.
- substituir os datamarts "silo" e os trabalhos ETL (pacotes SSIS) que atualmente carregam os datamarts por visualizações materializadas (também conhecidas como "indexadas") nos esquemas recém-definidos
- mover quaisquer tabelas usadas com operações CRUD do antigo datamart do aplicativo para o novo esquema correspondente no datamart "Staging Area" (precisa ser renomeado, pois agora cobre todo o data warehouse em um datamart)
- implementar uma API simples que apresenta solicitações GET para as visualizações definidas e POSTs para operações CRUD necessárias das tabelas do ponto 4
É claro que cada uma dessas etapas tem um grande impacto nas próprias soluções e no local de onde elas consomem os dados. Além disso, é claro que seriam necessárias muitas horas de desenvolvimento. Mas este não é o ponto por enquanto, é mais uma questão geral se isso faz sentido ou como você configuraria isso no SQL Server.
Tenho a sensação de que construímos muito em torno dos dados, o que também dificulta em outras áreas a melhoria/aceleração dos processos de back-end.
Muito obrigado antecipadamente e tudo de bom Benny