Eu tenho uma tabela de entidades. Para propósitos de exemplo, vamos chamá-los de Vehicles
: Car
, Boat
, Motercycle
, etc.
O ideal é colocar todas as entidades em uma única Vehicles
tabela porque muitas tabelas relacionadas ( VehicleRatings
, VehicleComments
, VehicleHistory
etc) serão aplicadas a qualquer entidade, não apenas a uma delas.
Mas algumas das entidades têm algumas propriedades individuais que não são compartilhadas com os outros tipos de entidade. No momento, há apenas 1 propriedade extra para uma entidade e 2 para outra. Espero que haja mais alguns que serão identificados mais tarde, mas não muitos no geral.
Como sei quando é melhor criar uma tabela filho para cada tipo de entidade para armazenar essas propriedades individuais, em vez de apenas adicionar uma coluna extra na Vehicles
tabela pai? Há alguma pergunta que eu possa fazer a mim mesmo para ajudar a determinar essa resposta?
Estou procurando otimizar principalmente o desempenho da consulta, seguido pela facilidade de manutenção.
De uma perspectiva lógica de ERD, o design apropriado é claramente o padrão de supertipo/subtipo de entidade. O que você está lutando é como implementar isso de uma perspectiva física.
Como muitos problemas de modelagem de dados, não há uma regra rígida e rápida. Você está olhando para um compromisso. Você deseja um pouco mais de complexidade na lógica e nas consultas de seu aplicativo (supertipo/subtipo) ou deseja correr o risco de que a lógica de seu aplicativo não imponha adequadamente suas restrições e que um registro de carro
vehicle
em sua tabela consolidada possa obter um valor não nulo valor naanchor_weight
coluna?Os tipos de coisas que você deve considerar ao decidir como negociar essas alternativas são:
No final das contas, você tomará uma decisão prática com base no que é mais importante para você. O que quer que você decida terá prós e contras - mas serão seus prós e contras.
Você pode querer examinar duas técnicas: herança de tabela de classe e chave primária compartilhada. Essas duas técnicas possuem tags que as descrevem no SO.
Aplicando essas duas técnicas ao seu caso, você pode acabar com um design mais simples, porém mais poderoso do que o que você propõe. Em alguns casos, você pode dispensar completamente o TypeID, porque uma junção entre a tabela generalizada e a tabela especializada apropriada produzirá exatamente os objetos que você está procurando. Além disso, como a junção está em duas chaves primárias, a junção será relativamente rápida.