Estoy pensando en cómo representar una estructura compleja en una base de datos de SQL Server.

Considere una aplicación que necesita almacenar detalles de una familia de objetos, que comparten algunos atributos, pero tienen muchos otros que no son comunes. Por ejemplo, un paquete de seguro comercial puede incluir cobertura de responsabilidad, motor, propiedad e indemnización dentro del mismo registro de póliza.

Es trivial implementar esto en C #, etc., ya que puede crear una Política con una colección de Secciones, donde la Sección se hereda según sea necesario para los diversos tipos de cobertura. Sin embargo, las bases de datos relacionales no parecen permitir esto fácilmente.

Puedo ver que hay dos opciones principales:

Cree una tabla de políticas, luego una tabla de secciones, con todos los campos requeridos, para todas las variaciones posibles, la mayoría de las cuales serían nulas.

Cree una tabla de políticas y numerosas tablas de secciones, una para cada tipo de cubierta.

Ambas alternativas parecen insatisfactorias, especialmente porque es necesario escribir consultas en todas las secciones, lo que implicaría numerosas uniones o numerosas comprobaciones nulas.

¿Cuál es la mejor práctica para este escenario?