Ereditarietà singola o polimorfico?

Question

Sono la programmazione di un sito web che permette agli utenti di inviare annunci con campi dettagliati per i diversi tipi di elementi che stanno vendendo. Tuttavia, ho una domanda circa il migliore schema del database.

Il sito offre molte categorie (ad es. Automobili, computer, macchine fotografiche) e ciascuna categoria di annunci hanno i loro campi distinti. Ad esempio, Auto hanno attributi quali il numero di porte, marca, modello, e la potenza mentre i computer hanno attributi come CPU, RAM, scheda madre modello, ecc.

Ora, poiché sono tutti gli annunci, stavo pensando di un approccio polimorfico, la creazione di un tavolo LISTA genitore e una tabella figlio diverso per ciascuna delle diverse categorie (computer, automobili, macchine fotografiche). Ogni tabella figlio avrà un listing_id che collegherà di nuovo alla lista delle TABLE. Così, quando un elenco è inverosimile, sarebbe recuperare una riga dal LISTA uniti da riga collegata nella tabella figlio associato.

LISTINGS
-listing_id
-user_id
-email_address
-date_created
-description

CARS
-car_id
-listing_id
-make
-model
-num_doors
-horsepower

COMPUTERS
-computer_id
-listing_id
-cpu
-ram
-motherboard_model

Ora, è questo schema un buon modello di progettazione o ci sono modi migliori per farlo?

I considerato l'ereditarietà singola ma rapidamente spazzato via il pensiero, perché il tavolo sarà troppo grande troppo in fretta, ma poi un altro dilemma è venuto in mente - se l'utente fa una ricerca globale su tutte le liste, allora questo significa che dovranno interrogare ogni tabella figlio separatamente. Che cosa succede se ho più di 100 diverse categorie, non sarebbe inefficiente?

Ho anche pensato ad un altro approccio in cui v'è una tabella principale (meta tabella) che definisce i campi di ogni categoria e un tavolo campo che memorizza i valori dei campi di ogni messa in vendita, ma sarebbe che vanno contro la normalizzazione del database?

Come avrebbero siti come Kijiji farlo?

Answer 1

Il vostro disegno di database va bene. Non c'è ragione di cambiare quello che hai. Ho visto la ricerca effettuata alcuni modi. Uno è quello di avere la ricerca stored procedure unire tutte le tabelle necessarie per la ricerca in tutto e indice le colonne da ricercare. Il secondo modo in cui ho visto fare, che ha funzionato abbastanza bene era di avere una tabella che viene utilizzata solo per la ricerca che ottiene una copia di qualsiasi campi che hanno bisogno di essere cercato. Poi si sarebbe messo trigger su quei campi e aggiornare la tabella di ricerca.

Entrambi hanno inconvenienti ma ho preferito il primo al secondo.

Modifica

Sono necessari i seguenti tabelle.

Categorie - Id - Descrizione

CategoriesListingsXref - CategoryId - ListingId

Con questo modello di riferimento trasversale è possibile partecipare a tutte le inserzioni per una determinata categoria durante la ricerca. Quindi aggiungere un po 'di SQL dinamico (perché è più facile da capire) e costruire la query per includere il campo (s) che si desidera effettuare la ricerca contro e call eseguire su vostra richiesta.

Questo è tutto.

EDIT 2 Questo sembra essere un po 'più grande discussione che possiamo pinna in queste caselle di commento. Ma, qualsiasi cosa vorremmo discutere può essere capito leggendo il seguente post.          http://www.sommarskog.se/dyn-search-2008.html

E 'davvero completa e mostra più di 1 modo di fare con pro e contro. Buona fortuna.

Answer 2

Credo che il disegno che avete scelto sarà un bene per lo scenario che hai appena descritto. Anche se non sono sicuro se le tabelle di classe sub dovrebbero avere il proprio ID. Dal momento che una macchina è un elenco, ha senso che i valori sono della stessa "dominio".

Nel tipico sito annunci, i dati per un annuncio viene scritto una volta e poi è fondamentalmente di sola lettura. È possibile sfruttare questa e memorizzare i dati in un secondo gruppo di tabelle che sono più ottimizzati per la ricerca in proprio il modo in cui si desidera che gli utenti di cercare. Inoltre, il problema di ricerca esiste veramente solo per una ricerca "generale". Una volta che l'utente sceglie un certo tipo di annuncio, è possibile passare alle tabelle sub di classe al fine di fare ricerca più avanzata (RAM> 4gb, cpu = sopraffatto).