struturas orientadas a objetos em bancos de dados relaciona

Pessoal

Pela n-ésima vez consecutiva, estou enfrentando o mesmo problema antigo novamente. É sobre "como mapeio estruturas de OOP para tabelas de banco de dados de maneira indolor".

Aqui está um cenário: eu tenho vários tipos de "atores" no meu sistema - trabalhadores, empregadores, contatos. Eles têm certas peças de funcionalidade em comum; outras peças são muito diferentes. As entidades com as quais todos os atores lidam são "comunicações", "anotações" (os administradores gostam de deixar anotações para os clientes) e muito mais. Existem vários tipos de outras entidades com as quais cada tipo de ator lida, enquanto os outros nã

tualmente, meu esquema de banco de dados inclui tabelas para:

Actors:

trabalhadoEmpregadocontat

Entidades

comunicaçãnota etc.

abelas de associação entre entidades e atore

trabalhador-comunicação-assn empregador-comunicação-assn notas-trabalhador-assn etc, você recebe a broc

Isto parece um "cheiro de código" para mim. Sempre que um cliente altera sua função (ou seja, promovido de "contato" para "empregador"), é necessário executar vários scripts malucos. Eca ... Por outro lado, se eu estivesse operando em um mundo puramente orientado para OOP, isso seria muito mais fácil - ter uma classe base para todas as entidades com propriedades comuns e concluir com isso ...

No mundo do DB, essa opção parece teoricamente possível, mas parece muito confusa ... se eu entendi direito, eu teria uma nova tabela base_actor, e cada outro ator teria um base_actor_id e as associações estariam entre o base_actor e as entidades ... Mas então, como faço para fazer consultas de associação inversa? I.e. "mostre-me todas as comunicações apenas com atores do tipo trabalhador"?

Algum conselho? Alguma opinião geral sobre o assunto "mapeamento de estruturas OOP para DB relacional"?

questionAnswers(11)

yourAnswerToTheQuestion