Longish. veja Resumo na parte inferior.
RDBMS
Um RDBMS significa sistema de gerenciamento de banco de dados relacional. É um sistema para gerenciar um banco de dados relacional. Os dados são armazenados lá. Os dados. Não diz lógica de negócios.
Processo de negócio
O que realmente significa lógica de negócios? Para mim, é uma descrição dos processos de negócios em termos lógicos.
Processos são aquelas atividades de negócios que ocorrem regularmente, o suficiente para que não sejam mais ad hoc. Estes são diferentes para cada empresa.
Deixe-me colocar meu limite de negócios e explicar o que são negócios aqui. Para alguns, isso pode ser uma surpresa.
O negócio
Negócio é a soma das atividades executadas para alcançar a criação de valor e, mais especificamente, o valor que pode ser negociado. Isso pode significar fazer colheitadeiras, sanduíches de atum ou fornecer serviços bancários. Na maioria dos países do mundo, mesmo naqueles em sistemas não capitalistas, as pessoas gostam de obter o melhor valor pelo seu dinheiro e, portanto, existe concorrência entre diferentes fornecedores desses bens e serviços valiosos. A competição geralmente depende de preço, qualidade e disponibilidade.
Desvio rápido: você precisa de 40 milhões de rebites em 2 dias, não vai pedir de um cara na internet com uma conta paypal, não importa o preço mais barato que o preço normal do seu fornecedor.
Processo de Conhecimento
Como você pode imaginar, os processos envolvidos para fazer esse "valor" residem principalmente nos chefes executivos. Parte disso é colocada no papel e usada como políticas e procedimentos da empresa. Parte disso mora nos chefes de consultoria corporativa. Muito disso vive na cabeça das pessoas que dirigem as divisões, departamentos, equipes e pessoas que administram as máquinas, as caixas registradoras, os fornos, os caminhões. Um pequeno subconjunto disso diminui os requisitos comerciais de software, e um subconjunto ainda menor é preciso quando é implementado em sistemas de computadores.
No final, a lógica de negócios que você vê no código não é a que administra um negócio, é a que executa o aplicativo para o negócio. O cérebro real dentro de pessoas reais mantém os processos de negócios reais e eles não têm problemas para entender que o processo em seu cérebro é mais preciso do que o processo no computador. Como um aparte, você provavelmente não poderia administrar o negócio se tudo o que tinha fosse as políticas e procedimentos da maioria das empresas. Muitas vezes, essas informações são imprecisas, apesar dos esforços hercúlicos.
Portanto, no final, é a lógica do aplicativo que está codificada no software. E as pessoas querem colocar isso no banco de dados, porque os fornecedores de sistemas de gerenciamento de banco de dados fizeram reivindicações grandiosas.
Lógica de Aplicação
Eu disse não. Eu digo que a lógica do aplicativo permanece dentro do aplicativo. Os dados vão para o banco de dados, de uma maneira muito normalizada, e depois encaminham a ETL ao dataware para relatório, perfuração e rollup, rotação e cubagem.
Dados
Eu também digo que os dados sobrevivem ao aplicativo, portanto, o esforço de normalização de dados não deve ser específico do aplicativo e nem mesmo específico do negócio, mas deve ser geral do negócio. Você armazena códigos de estado? Você deve usar o INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) porque é portátil nas empresas. Isso também facilita a manipulação de vários aplicativos pelos dados.
NoSQL?
Se você tratar o banco de dados como parte do código do aplicativo, do layout das tabelas aos gatilhos, procedimentos armazenados e formatos de dados, estará basicamente usando o banco de dados corporativo como um BerkleyDB glorificado, que é uma estrutura de arquivos simples glorificada, que são realmente apenas listas persistentes. Isso é essencialmente o que o NoSQL está fazendo: voltando às raízes, mas fazendo isso de maneira multi-processo, persistente e tolerante a falhas.
Código atual
Não, você precisa tratar o banco de dados como um repositório comum de dados para vários aplicativos, atuais e futuros. Agora chegamos ao cerne da minha discussão. Os processos de negócios mudam com os caprichos do mercado, da política e da moda. Muitas vezes, eles mudam mais rapidamente do que o que os codificadores podem gerenciar com linguagens de nível de ciência da computação (Java, C #, C ++ etc.) e acabam sendo escritos em VBA em planilhas do Excel no departamento de contabilidade ou marketing. (E somente se não puder ser expresso em visualizações sofisticadas ...)
Degradação de banco de dados
Os dados não mudam muito se estiverem bem organizados. A lógica de negócios muda muito rapidamente. Ao colocar a lógica comercial no banco de dados, você o torna menos valioso, porque se tornará obsoleto e impreciso mais cedo.
Sumário
Os dados devem sobreviver ao aplicativo porque os processos de negócios vivem no aplicativo e os processos de negócios mudam com muito mais frequência. A inclusão da lógica de negócios no banco de dados é ruim por sua longevidade e valor geral.
Embargo
Fiz minha parte no dba-ing e li as respostas no dba.se, mas com toda a honestidade o que eles estão falando são problemas de integridade de dados e problemas de desempenho. Concordo plenamente que as pessoas que tocam em dados corporativos devem saber o que estão fazendo, seja dba ou programador ou analista sênior do SAS com acesso de leitura / gravação.
Também observei que eles recomendam que os codificadores conheçam SQL. Concordo. É uma linguagem de programação de computadores, então não vejo por que os programadores não gostariam de saber.
Mais tarde, depois de pensar sobre isso
Acho que o meio termo é criar uma API e fazer com que essa API gerencie o fluxo de dados para lá e para cá. Se você não pode permitir que os aplicativos se conectem diretamente às tabelas, pelo menos você pode fazer com que o mecanismo de acesso esteja em idiomas modernos.