Especialização e generalização em banco de dados e desenvolvimento da aplicação

Eu tava pensando que suas especializações para livros fossem, por exemplo:

• Livros digitais
• Audiobooks
• Livros impressos

nos quais a natureza da experiência da leitura fosse diferente, em cada caso. Daí faria sentido uma especialização.

No mais, quanto ao critério de usar várias ou uma tabela, vai de acordo com a sua vontade, ou de acordo com a vontade do arquiteto de dados, basicamente.

Existe algum motivo para ter uma especialização? Se tiver, tem algum motivo para ter uma generalização? Pode parecer óbvio, mas uma das duas parecem estar erradas em modelagem relacional. Se está falando em especialização não tem porque falar de relação, são conceitos excludentes.

Não faça algo sem motivo. Pergunte-se qual o motivo de usar algo? Que problema isto está resolvendo? E quais estão sendo causados?

Você diz que que cada tipo de livro tem regras de negócio específicas. É mesmo? tem certeza? Vamos dizer que sim, e por que as regras de negócio estão no banco de dados? Vamos dizer que queira fazer assim, o que a pergunta já mostra que isto não é uma boa ideia, que solução vê a não ser separar cada tipo em uma tabela? Se o dado se comporta diferente precisa estar em tabela diferente. Eu só não faria assim, dentro da minha visão, pode ser que precise mesmo de algo fora do normal.

Uma solução é ter uma tabela só e algumas ações que dependem do tipo serem feitas de forma condicional.

Não tem impasse algum. Eu não vejo nada de especialização ou relacionamento aí, portanto não há dicotomia. Só tem regras de negócio diferentes que são programadas na aplicação. Ou no banco de dados se preferir assim. Mas não tem porque criar uma tabela nova se a estrutura é a mesma. Banco de dados não é aplicação, embora alguns achem que é.

Veja vantagens e desvantagens de por a regra de negócio no banco de dados.