Se, como declarado em sua postagem, a intenção é criar um banco de dados relacional (RDB por brevidade) e, portanto, espera-se que funcione como tal, a resposta curta será:
- Não, você não deve ignorar as restrições de integridade de dados .
O objetivo principal deve ser o de gerenciar os dados pertinentes, um ativo organizacional bastante valioso e uma maneira confiável de alcançar esse objetivo é empregar meios técnicos que são suportados por uma teoria sólida.
Assim, como profissionais de banco de dados, você pode tirar proveito dos mecanismos de modelo relacional modernos e modernos fornecidos pelo Dr. EF Codd para impor regras de negócios e evitar os problemas que eventualmente surgiriam se eles não forem utilizados.
A esse respeito, compartilharei (a) minha visão geral das restrições e (b) várias considerações sobre o estado das coisas no banco de dados e o ambiente de trabalho em questão da seguinte forma.
Restrições de chave estrangeira, relacionamentos de dados e integridade referencial
Um RDB deve refletir as características do contexto de negócios de interesse com alta precisão, o que definitivamente requer uma análise aprofundada em nível conceitual liderada por um modelador ou designer que segue as melhores práticas, contando com a assistência indispensável dos especialistas em negócios. Essa análise deve fornecer a identificação e formulação corretas das regras de negócios aplicáveis .
Consequentemente, se esse modelador identificou a existência de inter-relações entre os dados relevantes, ele ou ela deve configurar as restrições de nível lógico correspondentes para que o sistema de gerenciamento de banco de dados (DBMS) possa garantir que os dados permaneçam consistentes com as características exatas e regras determinadas na análise acima mencionada em todos os momentos .
Com relação ao banco de dados em discussão, pode-se inferir que as inter-relações pertinentes foram identificadas, pois você menciona que existe uma tentativa processual (e fácil de contornar) de aplicá-las fora das instalações do DBMS, por meio do código do programa aplicativo (que é uma abordagem pré-relacional) que, em qualquer caso, precisa "tocar" o banco de dados para tentar validar a totalidade das referidas inter-relações.
No entanto, como você sabe, essa não é a técnica ideal para proteger a integridade referencial , porque a ciência relacional prescreveu um instrumento muito poderoso para esse fim, ou seja, restrições de FOREIGN KEY (FK). Essas restrições são muito fáceis de criar (por meio da abordagem declarativa superior), pois são frases únicas que evitam recorrer a procedimentos ad hoc desnecessários e propensos a erros. É muito útil observar que a velocidade de execução das restrições do FK foi altamente otimizada por programadores especializados (e os principais fornecedores de plataformas já trabalham nisso há décadas).
Além disso, como um RDB deve ser um componente de software independente (autoprotetor, autoexplicativo etc.) capaz de ser acessado por vários programas aplicativos (desktop, automático, web, móvel, combinações dos mesmos), não deve ser "Acoplado" ao código de qualquer um desses aplicativos.
Da mesma forma, os dados - sendo um recurso organizacional significativo - naturalmente tendem a sobreviver a programas de aplicativos, programadores de aplicativos, plataformas de desenvolvimento de aplicativos e paradigmas de programação.
Restrições de PRIMARY KEY e implicações de linhas duplicadas
Quando, conceitualmente, um tipo específico de coisa é considerado significativo em um ambiente de negócios, um modelador de banco de dados precisa (1) determinar suas características relevantes - ou seja, suas propriedades -, confirmar esse tipo de coisa como um protótipo de instância de entidade - ou seja, um tipo de entidade - e (2) representa-o por meio de uma tabela que é integrada por uma ou mais colunas em um design lógico.
Então, assim como é fundamental distinguir cada instância individual de um determinado tipo de entidade no mundo real, cada linha incluída em uma tabela também deve ser diferenciada exclusivamente. Se uma tabela não tiver nenhuma KEY declarada, ela reterá duplicatas e, se houver duas ou mais linhas que mantêm exatamente os mesmos valores, todas elas terão o mesmo significado , todas elas representarão o mesmo fato .
Nesse ponto, linhas duplicadas devem ser descartadas devido a vários motivos. Do ponto de vista teórico, o designer deve garantir que cada linha seja sempre única com o objetivo de ter tabelas que funcionem tão relacionalmente quanto a sub-linguagem de dados SQL permitir (com importantes repercussões nas operações de manipulação de dados). Além disso, do ponto de vista informacional, se várias linhas representam o mesmo fato, seu registro não é apenas supérfluo, mas prejudicial , como exemplificado abaixo:
- Suponha que alguém tenha inserido duas linhas idênticas em uma determinada tabela.
- Mais tarde, alguém chega e atualiza apenas uma ocorrência das duplicatas. Como conseqüência, a outra ocorrência não está mais atualizada.
- Sucessivamente, outra pessoa atualiza a ocorrência que não havia sido modificada até o momento. Dessa maneira, ambas as duplicatas sofreram alterações diferentes em momentos distintos.
- Depois disso, quando alguém estiver interessado em selecionar as informações transmitidas pelas linhas em questão, poderá encontrar duas "versões" diferentes.
Nesse caminho:
- Qual "versão" pode ser considerada a correta e confiável?
- Qual deles reflete o mundo real com precisão?
Como você sabe, esse fenômeno pode até ter implicações legais, uma circunstância que certamente é de enorme importância.
Além disso, o tempo e o esforço que devem ser empregados para lidar com tais contradições (talvez através de algum tipo de "sincronização de atualização") devem ser mais dedicados a tarefas que realmente produzem valor para sua organização. Portanto, reter linhas contraditórias deve ser evitado pelo design para manter intacta a consistência de um banco de dados.
É por isso que a identificação de uma PRIMARY KEY (PK) e a declaração da respectiva restrição devem sempre ser executadas pelo designer do banco de dados. Mas também deve ser mencionado que uma tabela pode ter mais de uma coluna ou combinação de colunas que contêm valores que identificam exclusivamente cada linha; como conseqüência, além de configurar uma restrição PK (idealmente estabelecida como PRIMÁRIA por motivos pragmáticos), o designer também deve declarar uma ou mais CHAVES ALTERNATIVAS (geralmente definidas por meio de uma ou mais restrições UNIQUE e NÃO NULA) quando aplicável (o que é bastante comum).
Outra propriedade vantajosa das PKs é que, quando “migradas” para outras tabelas para participar de FKs únicas ou compostas, elas podem ajudar a impor as proporções de cardinalidade dos relacionamentos existentes entre os dados. Tudo isso, sim, por meio de configurações declarativas simples e eficientes, garantidas pelo DBMS.
Restrições CHECK (atuais) e validação de linha única
Não esqueçamos a relevância das restrições CHECK (atuais) que, restringindo declarativamente o conjunto válido de valores de colunas de uma linha (que podem parecer simples, mas são de fato um recurso fundamental de um DBMS relacional), ajudam também a tornar certo de que as regras do contexto comercial são refletidas com precisão o tempo todo.
Como você marcou sua pergunta com a tag MySQL, deve-se mencionar que, infelizmente, essa plataforma permite a declaração desse tipo de restrição, mas, ao mesmo tempo, ignora sua aplicação! , situação que, compreensivelmente, foi relatada como um bug desde 2004 .
Nesse sentido, você teria que cuidar desse fator por outros meios, por exemplo, TRANSACÇÕES ÁCIDAS, DISPARADORES ou outros métodos dentro do próprio DBMS (consulte esta resposta do @ ypercubeᵀᴹ
para obter informações sobre este assunto) para que os dados continuem a ser consistente.
Restrições de ASSERÇÃO: configurando regras de negócios adicionais de várias linhas e várias tabelas declarativamente
Um aspecto que, por qualquer motivo, é pouco suportado - se é que - pelos diferentes DBMSs do SQL, incluindo o MySQL, está permitindo restrições de várias linhas e várias tabelas de maneira declarativa - além de PKs e FKs, evidentemente -.
Por seu turno, o padrão SQL inclui ASSERÇÕES de muitos anos. Não sei quais regras do seu ambiente de negócios se beneficiariam dessa abordagem de validação em nível lógico, mas, como designer de banco de dados, considero que seria bastante útil restringir dados com uma ou mais ASSERÇÕES, embora eu deva mencionar isso no do ponto de vista dos desenvolvedores do DBMS, esse tipo de ferramenta primordial tem sido difícil de implementar no nível físico da abstração.
Parece que o fornecedor e / ou desenvolvedores da Oracle estão avaliando o suporte do ASSERTION desde 2016, e isso tornaria o DBMS mais compatível com o relacionamento e, portanto, mais robusto e competitivo. Eu acho que, se (i) seus consumidores continuarem pressionando e (ii) a Oracle for bem-sucedida na implementação, (iii) outros fornecedores / comunidades de DBMS precisarão habilitá-los também, e seu uso começará a se espalhar. Certamente, isso seria um enorme progresso no campo de gerenciamento de banco de dados e, sendo uma das ferramentas mais distintas previstas pelo Dr. Codd, eu pessoalmente espero que isso aconteça em breve.
Consistência dos dados e processo de tomada de decisão
Como discutido acima, um dos aspectos mais importantes de um RDB é que ele garante por si só a consistência dos dados que retém, e essa consistência só é atendida quando o RDB está em conformidade com as restrições de integridade declaradas pelo modelador.
Nesse sentido, é obrigatório ter tabelas de base (aquelas estabelecidas em uma estrutura DDL) cuja integridade esteja protegida para poder criar tabelas derivadas (por exemplo, uma instrução SELECT ou exibição que recupera colunas de várias tabelas) que sejam confiáveis , porque as tabelas derivadas precisam ser produzidas necessariamente em termos de tabelas base.
É sabido que as pessoas usam as informações como a principal ferramenta no processo de tomada de decisão organizacional (e no comum). Então, se as informações apresentadas por um banco de dados não forem coerentes e precisas, as decisões baseadas nessas informações não serão sólidas (para dizer o mínimo). É por isso que um RDB deve ser cuidadosamente projetado e implementado: ele deve ser construído para se tornar um recurso confiável que pode ajudar seus usuários a tomar decisões fundamentadas.
"Desnormalização"
Infelizmente, “um banco de dados 'desnormalizado' é mais rápido que um banco de dados normalizado” é um equívoco amplamente difundido, embora também seja um argumento que pode ser refutado em bases lógicas, físicas e pragmáticas.
Em primeiro lugar, a desnormalização implica necessariamente que uma tabela de base tenha sido previamente normalizada (em virtude de um procedimento formal , baseado na ciência, realizado no nível lógico de abstração de um banco de dados).
Portanto, supondo que a tabela tenha sido de fato normalizada corretamente, "desnormalizando-a" (que, em contraste com o significado formal da palavra, envolve anexar a ela colunas que pertencem a outras tabelas de um anúncio e também fazem parte dela moda hoc ) pode ajudar, por exemplo, a acelerar (no nível físico) o processamento de apenas uma ou algumas instruções SELECT específicas, enquanto esse curso de ação pode, ao mesmo tempo, minar a execução de muitos outros dados associados operações de manipulação (por exemplo, várias instruções INSERT, UPDATE, DELETE e SELECT ou combinações delas incluídas em uma única ou múltiplas TRANSACÇÕES ÁCIDAS).
Além disso, a desnormalização (formal ou informal) introduziria anomalias de atualização / modificação que deterioram a coerência do banco de dados, um problema que “pode” ser tratado por procedimentos complexos, dispendiosos e propensos a erros, quando tudo isso pode ser impedido de o começo.
Andaimes de nível físico que suportam tabelas normalizadas e "desnormalizadas"
Um layout lógico (abstrato) (design SQL-DDL) que deve ser utilizado no mundo real contém claramente repercussões físicas (concretas) que devem ser consideradas.
Dessa maneira, uma tabela "desnormalizada" seria necessariamente "mais larga" (mantendo colunas adicionais), o que significa que suas linhas seriam necessariamente mais pesadas (exigindo mais e maiores componentes no nível físico), de modo que os processos de computação subjacentes (por exemplo, , aqueles que têm a ver com o disco rígido ou a memória) podem facilmente ficar mais lentos.
Por outro lado, uma tabela normalizada que é obviamente "mais estreita" (com menos colunas) seria um elemento "mais leve" (servido por componentes físicos cada vez menores) que "se comporta mais rápido", o que aceleraria a série de ações relacionadas a por exemplo, gravação e leitura de dados.
Sendo assim, é muito conveniente (a) normalizar as tabelas relevantes formal e prudentemente, mantendo-as como tal, e (b) utilizar qualquer recurso de nível físico que possa otimizar a velocidade de recuperação e modificação de dados, por exemplo, implementar uma estratégia de indexação cuidadosa e eficiente, permitindo configurações adequadas de servidores de software e hardware, atualizando os recursos de largura de banda da rede etc.
O funcionamento do banco de dados em consideração
Os parágrafos a seguir da sua pergunta têm a ver com a velocidade das operações de recuperação de dados:
[A] s o produto “funciona”, há hesitação em aprimorar o banco de dados; no entanto, a primeira coisa que notei é uma página que leva 1 minuto para carregar (sim, 60 segundos!).
Se o carregamento de uma determinada página leva muito, é evidente que os usuários do sistema não estão recebendo um bom serviço; portanto, mesmo quando "funciona", seu funcionamento não parece ótimo, ponto que demonstra que suas intenções de tornar todo o ambiente (banco de dados e aplicativos) mais eficientes são bem sustentadas e mostram uma atitude muito construtiva.
Então, mesmo quando a ciência definitivamente o apoia e, portanto, você deve manter uma postura firme, sugiro abordar a situação de maneira diplomática, pois no final do dia, seus empregadores, colegas e você estão se unindo aos esforços para tornar toda a organização mais bem sucedido. Portanto, esse é um argumento que você deve enfatizar: enquanto eles estão fazendo outras coisas mais do que bem, melhorar as práticas gerais e específicas de gerenciamento de dados pode ajudar consideravelmente na produção de mais crescimento organizacional e individual.
A maioria das consultas relevantes inclui operações JOIN, o que as torna executadas muito, muito, muito lentamente, com grandes quantidades de dados (o banco de dados contém milhões de linhas).
Vale ressaltar que o operador JOIN é um elemento essencial e poderoso que pertence à manipulação relacional de dados. Então, embora plataformas mais robustas o atendam com execuções comparativamente mais rápidas, a circunstância que você descreve é provavelmente um sintoma de um design não eficiente (nos níveis conceitual, lógico e físico de abstração). Então, minhas primeiras estimativas à vista são:
- As configurações de INDEX podem exigir melhorias.
- As definições de tipo e tamanho de colunas PK e FK precisam ser revisadas (e eu concordo totalmente com @ James James sobre suas considerações sobre PK , pois as KEYs compostas tendem a ser muito mais eficientes do que as substitutas anexadas nos casos apropriados).
- Uma normalização adicional (formal, baseada na ciência) pode ajudar a aliviar esses problemas, devido ao fato de que, nas circunstâncias corretas (isto é, realizadas em um RDB bem projetado), os JOINs são executados muito rapidamente .
Além disso, sim, como o @TommCatt menciona em sua resposta , às vezes uma reescrita (lógica) de uma consulta modifica seu plano de execução (físico), acelerando a leitura / gravação de dados, que é um fator que deve ser decididamente levado em consideração.