Sto creando un'app di noleggio che ha molte categorie con proprietà uniche
Esempio:
Category 1
Car which has
Fuel, model, color, speed
Category 2
Apartment which has
Rooms, lift, generator, floors
Ho pensato a un'architettura db per questo tipo di progetto, ma non sono riuscito a trovare nessuno in grado di gestire questo concetto di categoria flessibile in modo performante e scalabile.
Normalmente vado con:
table RentableThings
Id PK //guid obvs
Type //car, flat etc
CommonProperty //eg name, date etc
table Cars
Id PK FK = RentableThings.Id
Fuel
Model
etc
table Apartment
Id
Rooms
Lift
etc
Quindi si seleziona dalla tabella comune o dalla tabella comune unita alla tabella speciale come richiesto
Questo è un problema vecchio come la ricerca sul database orientato agli oggetti, poiché le tue categorie corrispondono a classi che hanno proprietà diverse. Fortunatamente, ci sono molte alternative.
L'approccio più ovvio e flessibile consiste nell'utilizzare una identità dell'oggetto per scomporla in elementare dati che vengono poi assemblati / disassemblati secondo necessità. È possibile modellare quasi tutti i tipi di categorizzazione in questo modo, ma l'assemblaggio / disassemblaggio è costoso. E avresti anche bisogno di alcuni controlli per garantire la coerenza degli attributi memorizzati con le aspettative della categoria / classe dell'oggetto.
Se andate in questo modo, usereste una tabella master degli oggetti con identificatori di oggetti univoci archiviati con alcuni metadati, come ad esempio la categoria / classe dell'oggetto. Gli attributi dell'oggetto sarebbero quindi memorizzati separatamente come una serie di triplette di object id + attribute key + attribute value utilizzando un qualche tipo di schema di accesso chiave / valore. In un RDBMS diversi tipi di valori ( int , float , string ) sono generalmente memorizzati in tabelle di terzine diverse. Un'alternativa comune è utilizzare un negozio di tuple no-sql .
Una variante consiste nell'utilizzare una tabella diversa per ogni attributo diverso, con il vantaggio dell'indicizzazione sui valori.
Un'altra variante è raggruppare diversi attributi in una tabella. In realtà, questa variante è ciò che ottieni usando il pattern di ereditarietà della tabella (vedi sotto).
Una variante consiste nel memorizzare un oggetto in un negozio di documenti . Questi database sono ottimizzati esattamente per questo scopo. MongoDB, ad esempio, memorizza i dati json in un oggetto binario bson , per un accesso rapido e un overhead ridotto.
Un altro approccio consiste nell'utilizzare un RDBMS con uno dei soliti schemi ORM per associare diverse classi a tabelle diverse: Eredità della tabella singola , Ereditarietà delle tabelle di classe e L'ereditarietà delle tabelle in calcestruzzo di solito fa il lavoro molto bene.
Esegui una ricerca sul Web con queste due frasi: "Ereditarietà della tabella singola" e "Ereditarietà della tabella delle classi". Troverai molti articoli di persone che hanno già lavorato sullo stesso tipo di problema. Alcuni articoli si basano sul libro di Martin Fowler, Modelli di architettura di applicazioni aziendali . Quello che segue è un breve riassunto di ciò che dicono alcuni articoli.
Auto e Appartamento sono sottoclassi di una classe più generica, che chiamerò RentalItems o semplicemente articoli. se si dovesse costruire un modello a oggetti per questo scenario, si utilizzerà la funzione di ereditarietà delle sottoclassi per svolgere gran parte del lavoro. La tua app può riflettere questo.
Il modello di dati relazionali, come tale, non ha caratteristiche per l'ereditarietà. Alcuni prodotti di database hanno aggiunto funzionalità per supportare l'ereditarietà, ma MySQL non è uno di questi, per quanto ne so. Quindi il problema diventa come progettare un sistema di tabelle che imiterà l'ereditarietà e renderà più semplice per la tua app recuperare i dati di cui ha bisogno.
L'ereditarietà di una tabella riunisce tutti gli articoli noleggiati in un unico grande tavolo, con molte colonne (campi) che riguardano solo le auto o riguardano solo gli appartamenti, ecc. Questo è abbastanza semplice e facile, ma finisce con molto di NULLS nei dati. I NULL possono rendere vagliando i dati un po 'confusi e lenti.
L'ereditarietà della tabella delle classi implica la creazione di una singola tabella generica, chiamiamola oggetto, per tutti gli articoli noleggiati. Questa tabella contiene proprietà comuni a tutti gli articoli in affitto, come la descrizione e il prezzo. Poi ci sono tabelle specializzate per auto, appartamento, ecc. Contenenti dati specializzati che riguardano ciascuna sottoclasse.
Potresti voler fare in modo che tutte le tabelle, oggetti, auto, appartamento, ecc. usino la stessa chiave primaria condivisa. Questa chiave, chiamiamola ItemID, è definita nel solito modo nella tabella degli articoli generica. Nelle altre tabelle, viene dichiarato come chiave primaria e anche come chiave esterna che fa riferimento a ItemID nella tabella degli articoli. Quando si devono aggiungere nuovi elementi, l'app si occupa di inserire le proprietà corrette nelle tabelle corrette e anche di propagare ItemId dalla tabella Item a una o più delle altre tabelle.
Potresti voler aggiungere viste per fornire viste congiunte su Car e Item, Apartment e Item, ecc. Queste viste congiunte verranno eseguite abbastanza velocemente per quantità moderate di dati, a causa degli indici che vengono creati quando si dichiara una chiave primaria.
Questo è solo un contorno. Gli articoli hanno esempi, diagrammi e simili.
Leggi altre domande sui tag database mysql database-design relational-database