Rappresenta la lista di oggetti polimorfi in db

Question

Rappresenta la lista di oggetti polimorfi in db

#1 da (1 voti)

1

Supponiamo di avere una lista di oggetti derivati da qualche base:

class Circle : public Shape;
class Rectangle : public Shape;

C'è un oggetto, che ha il vettore di Shape * come variabile membro:

class Screen {
    std::vector<Shape *> shapes_;
}

Ma ora ho bisogno di persistere nel database (PostgreSQL per essere precisi). L'unico modo che ho pensato è avere una tabella per classe, qualcosa del genere:

table screen ();

table circle (
    int screen_id;
);

table rectangle (
    int screen_id;
);

E dopo aver recuperato dall'oggetto di tipo Schermo, esegui una ricerca di cerchie e rettangoli con screen.id. Dovrebbe essere fattibile.

Tuttavia temo che quando il numero di tipi crescerà (e lo sarà), significherebbe molte query db per un solo oggetto recupero / persist.

Sapete che avremo circa 10 tipi che penso? Quelle sono 11 query db solo per recuperare un oggetto Screen.

Quindi la mia ricerca è, c'è un modo migliore per raggiungere il mio obiettivo? Sto bene con la riprogettazione del mio codice, se necessario, vorrei solo qualche soluzione O (1) in correlazione al numero di tipi (la mia soluzione è O (n)).

Grazie ragazzi ^ _ ^

NOTA: in base al commento, aggiungo che le tabelle di cerchi e rettangoli e così via verranno utilizzate solo per mettere insieme oggetto Screen. Non riesco ad accedere (cercare, recuperare, persistere, ...) a loro individualmente, solo come parti di Screen (s). Non hanno nemmeno bisogno di essere nel loro tavolo. Semplicemente non ho trovato il modo di mettere tutto insieme bene: /

database database-design postgres

posta graywolf 03.10.2014 - 12:03

fonte

1 risposta

Leggi altre domande sui tag database database-design postgres

Che cosa sono esattamente i valori di link relation? Devo rilasciare i miei plugin AGPL

score 1 · Accepted Answer

Tutto ciò di cui hai bisogno è un tavolo, con un design semplice. Hai bisogno di

Un campo per l'uid
Forse un campo per un timestamp (potresti averne bisogno, non puoi, non conosci le tue particolari circostanze).
Un campo in cui serializzi l'oggetto Screen e tutti le forme che contiene.

Ciò significa solo una scrittura da salvare e una da leggere per recuperare lo schermo e le sue forme. Perché fare di più, data la semplicità dei tuoi requisiti?

Ti consiglio di serializzare su un formato JSON. Postgresql ora ha un tipo di dati JSON e gli operatori e le funzioni JSON. Quindi puoi convalidare ed esaminare i dati serializzati nel db se lo desideri, senza doverlo estrarre e normalizzare.

Altri vantaggi di questo approccio:

Se in seguito deciderai di serializzare da qualche altra parte (in un file o in una memoria cache, ad esempio), richiederebbe una modifica minima del codice.
Non è necessario modificare lo schema db se aggiungi nuovi tipi di forme o modifichi la struttura di qualsiasi oggetto esistente.