Doutrina e Propel usam a herança de tabela única e concreta para mapear relacionamentos de objetos. O primeiro vê todos os campos possíveis na árvore de classes mapeados para uma única tabela - enquanto o último mapeia cada classe para uma tabela específica, duplicando campos comuns na hierarquia de herança.
Embora isso facilite o aparelho ORM, ele sugere um design ruim do banco de dados. Esses padrões de design incorretos devem ser aplicados em um banco de dados?
Respostas:
É impossível dizer se um design de banco de dados específico é ruim sem saber o que o aplicativo está fazendo, a forma dos dados, as expectativas de desempenho e assim por diante. Embora geralmente a normalização (até certo ponto) seja vista como uma prática recomendada, é bastante comum desnormalizar áreas de bancos de dados por razões de desempenho tão boas e ruins são muito abertas para discussão sem muito mais dados do que a maioria das pessoas quando inicia.
Adicione as muitas abordagens que podem ser adotadas para objetar aos mapeamentos relacionais e as coisas se tornam ainda mais complexas, pois a "melhor" estrutura de banco de dados dependerá do modelo de objeto específico, do nível de herança e assim por diante.
Ao adotar uma abordagem de tamanho único, as bibliotecas de persistência ORM quase sempre produzem uma estrutura de banco de dados não ideal para qualquer situação e usam algumas coisas que podem ser vistas como uma má prática para uma determinada situação .
Você certamente poderia escrever um ORM que normalizasse, mas veria implicações de desempenho bastante pesadas, pois para cada inserção em uma tabela principal era necessária a varredura das várias tabelas de consulta para verificar se existiam valores, se obtiveram suas chaves e se não obtiveram. execute as inserções relevantes.
(Quando você faz isso manualmente, pode cortar um pouco disso, pois sabe que os apresentou com uma lista suspensa contendo apenas um valor válido, para que você não precise fazer essas pesquisas, basta usar a tecla feliz como está indo para ser válido, o ORM não pode fazer essa suposição, pois não controla a interface do usuário.)
Mas o que você deve se lembrar é que eles não pretendem otimizar o desempenho do banco de dados ou a integridade dos dados, mas sim a velocidade do desenvolvimento . Se a estrutura específica de seus dados é importante para você, você precisa codificar seus mapeamentos de objeto / RDBMS manualmente ou, pelo menos, fazer uma avaliação detalhada de todas as bibliotecas disponíveis e selecionar a que melhor atenda às suas necessidades ( se existir).
Essencialmente, tudo se resume a requisitos e à troca entre dados bem estruturados, desempenho do banco de dados e velocidade de desenvolvimento. Tal como acontece com muitos trade-offs, você não escolhe todos os três.
Não concordo que o ORM promova a desnormalização ou o design incorreto do banco de dados. De fato, os piores bancos de dados projetados que eu já vi foram feitos sem ORMs. Ao simplificar o relacionamento adequado com base no ID da linha, em vez de estabelecer uma relação com o valor de um campo aleatório, promove um bom design do banco de dados.
Possivelmente, isso não promove a normalização, mas, novamente, um ORM, onde é fácil criar tabelas / objetos e relações, quase pode ser visto para promover isso também. Não é muito mais trabalhoso em um ORM criar uma tabela "local" com endereços e vincular funcionários ao local em vez de adicionar o endereço à tabela de funcionários. Porém, sem o ORM, separar o local significa que toda vez que você deseja acessar o local também, é necessário fazer uma associação.
Então, minha resposta é: não, acho que não . Possivelmente, de outra maneira, um bom ORMs incentiva um bom design de banco de dados, pelo menos sobre aqueles que têm pouca experiência.