Ok, não consegui encontrar um título melhor, para ser honesto.
Recentemente, cheguei a um novo local de trabalho e me pediram para ajudar com o banco de dados. Eu queria tentar explicar um conceito, mas não tenho certeza de como expressar isso na melhor das hipóteses, e talvez esse conceito já tenha uma explicação melhor e um nome também. Eu não me classifico como um especialista em DB, então gostaria de apresentar a eles algo mais oficial do que meu próprio ponto de vista, não importa quantos bons DBs eu tenha projetado em minha vida.
Uma das coisas que achei mais divertidas (mas não no bom sentido) é que eles parecem seguir o design do db de acordo com a lógica do problema e não de acordo com "este é um banco de dados, deve conter dados", então por exemplo para saber se um elemento está em uma determinada categoria, a consulta fica assim (em pseudocódigo):
SELECT Column1, Column2...ColumnN
FROM Invoices [LIST OF JOIN]
WHERE
Invoces.Field1 IN
(TableA WHERE TableA.Field NOT IN
(TableB WHERE TableB.Field IN ((TableC WHERE) OR (TableD WHERE)))
OR Invoces.Field1 NOT IN
(TableB WHERE TableB.Field IN ((TableC WHERE) AND (TableD WHERE))
OR TableB.Field IN
(TableC WHERE TableC.Field IN (TableC WHERE))
OR TableB.Field NOT IN
(TableC WHERE TableC.Field NOT IN (TableD WHERE))
e assim por diante para outras vinte condições. Não, não estou brincando.
Isso acontece porque ao invés de dizer "esta é uma fatura e sua categoria é um atributo da própria fatura", eles vão até o fim com coisas como "a fatura foi inserida por aquele usuário, naquele dia, e ele poderia ter inserido em um determinado departamento ou em nenhum, e no caso do departamento, então esse departamento pode ser parte de uma certa estrutura..." e assim por diante. Não é nem uma questão de integridade referencial, não há FKs neste caso...
Outro exemplo prático é a data da última edição de um documento: ao invés de ser armazenado como um atributo, é calculado por uma função que segue algo assim:
se esse documento estiver relacionado a outro, então se o outro for deste tipo, então se o primeiro documento estiver relacionado a este outro documento também, então a data da última edição é a data em que o administrador imprimiu o calendário diário de compromissos". .
claramente com um monte de outros para cada se, também. E, não é porque há algum tipo de dependência, é apenas porque muitas coisas são armazenadas para refletir sua lógica.
De certa forma, ficaria tentado a dizer "escreva uma vez, leia muitos", com o significado de "escreva esse atributo uma vez e depois leia de graça quantas vezes precisar", porque temos uma baixa frequência de gravações e uma frequência muito alta de leituras, e claramente todas as leituras devem sempre recalcular tudo. Mas tenho a sensação de que deve haver algum princípio que diz que você deve projetar bancos de dados para armazenar dados...
Depende
A finalidade de um banco de dados é armazenar
valid data
de forma segura para vários usuários em vários aplicativos.Parte da lógica se concentrará na
valid data
parte dessa declaração. Estes serão seusconstraints
edata types
.Outras partes do código dentro do banco de dados se concentrarão na
multiple applications
parte. Por exemplo, aVIEW
ocultará alguma lógica complexa para garantir que todos os aplicativos vejam os dados de maneira idêntica. Um aplicativo pode ser um aplicativo baseado na Web, o outro aplicativo pode ser um gerador de relatórios de terceiros.OLTP
Dentro de um sistema OLTP, a instrução complexa
SELECT
e alast modified date
lógica não fazem muito sentido.Se isso for um sistema OLTP, você deve tentar mudar as coisas para que elas sigam as práticas normais de banco de dados relacional.
Armazém de dados
A complexidade de sua declaração de pseudocódigo
SELECT
e suadate of last edit
lógica fazem todo o sentido em um ambiente de Data Warehouse [DW]. No entanto, eles provavelmente fazem parte de um processo ETL/ELT para materializar os dados em uma tabela desnormalizada para geração de relatórios mais rápida.Os
TABLES
andVIEWS
eMATERIALIZED VIEWS
são criados para resolver um conjunto muito específico de problemas de negócios. Pela minha experiência, esses objetos são usados como fonte para vários Relatórios de Negócios. Em alguns casos, uma tabela/visualização por relatório é criada para resolver um Requisito de Negócios.Não
FKs
? Isso é provavelmente normal para um DW. Os dados nas tabelas podem ser atualizados comTRUNCATE
seguido deINSERT...SELECT
. Nesta situação, aForeign Key
poderia fazer mais mal do que bem.Ao ler os comentários, parece que sua empresa precisa mudar para um design hierárquico OLTP mais formal. Eu te desejo sorte.