Come strutturare strutture simili usando Go e PostgreSQL senza troppo codice duplicato

Sto creando un'API REST in Go utilizzando PostgreSQL.

Introduzione rapida:

Ho improvvisamente un caso in cui ho diverse varianti della stessa entità di base, una delle varianti ha forse 12 campi in più rispetto alla base e altre due varianti hanno alcuni campi in più. Ho mappato questo usando la sintassi Inherits in Postgres che mi fa risparmiare un sacco di tempo, ma non è altrettanto ricco di funzionalità, ma ti dà alcuni vantaggi se vuoi selezionare da tutte le tabelle figlio allo stesso tempo, ad es. un'unione che recupera solo i campi base. Ma pone problemi quando non si vuole capire in quale tabella figlio sia presente un ID specifico.

Il mio problema reale:

Implementare un GetOne tenendo solo un ID senza inquinare il mio contratto API pubblico con complessità non necessaria. L'ID potrebbe appartenere a uno qualsiasi dei bambini e ha bisogno di tutti i campi da quella tabella figlio. Ho utilizzato le strutture incorporate in Vai per mappare l'ereditarietà nelle strutture e l'ereditarietà utilizzata nel database, quindi mi piacerebbe davvero una soluzione carina per legare insieme questa cosa. Stavo pensando ad alcune soluzioni a questo problema molto classico, come segue:

• Perfeziona la mia API restful dicendo "okay queste entità sono diverse" e crea un entity/<type>/<id> di endpoint, quindi eseguirò una normale logica di commutazione nel mio store che avrebbe un modello per ciascuno di queste entità.

• Crea una stored procedure gestendo tutto questo nel database, e quando il risultato ritorna eseguo qualche tipo di controllo che vede quali campi sono tornati e da quello identifico il tipo, potrei ad esempio introdurre un campo type nella base delle entità per renderlo facile da convalidare. Vorrei quindi solo restituire un interface{} dal modello che è una specie di variabile generica che può contenere qualsiasi cosa e restituirla direttamente al codice cliente. Ciò nasconderebbe sicuramente la complessità, ma non sembra un modo molto idiomatico di andare a farlo.

• Potrei separarli completamente e creare controller, modelli e archivi per ciascuna di queste varianti di tipi che è molto digitazione e difficile da estendere, quindi penso che vorrei evitarlo.

Non penso che PostgreSQL abbia qualcos'altro da offrirmi funzionalità che risolvono il problema, sono stato molto lontano dai modelli di design - non mi sorprenderebbe se potesse essere risolto con una strategia modello o modelli strutturali simili.