Database relazionale di pianificazione: una o due tabelle?

Question

Database relazionale di pianificazione: una o due tabelle?

#1 da (5 voti)
#2 da (3 voti)
#3 da (2 voti)
#4 da (0 voti)
#5 da (0 voti)

2

Attualmente sto pianificando la struttura del database del sito di annunci di un'auto usata. Ogni annuncio contiene informazioni su un veicolo, e un veicolo può essere pubblicizzato più volte nel corso della sua vita (concesso, abbastanza improbabile). Non sono sicuro di quale approccio adottare: una tabella singola o due tabelle relazionali separate, ognuna ha i suoi pro e contro.

Schema 1

Adverts Table:
-------------------
id            int
make          varchar(255),
model         varchar(255),
year          int,
transmission  varchar(255),
fuel_type     varchar(255),
body_type     varchar(255),
engine_size   int,
colour        varchar(255),
doors         int,
location      varchar(255),
price         int,
owners        int,
mileage       int,
description   longtext

Schema 2

Adverts Table
-------------------
id            int
location      varchar(255),
price         int,
owners        int,
mileage       int,
description   longtext
vehicle_id    int

Vehicles Table
-------------------
id            int
make          varchar(255),
model         varchar(255),
year          int,
transmission  varchar(255),
fuel_type     varchar(255),
body_type     varchar(255),
engine_size   int,
colour        varchar(255),
doors         int

Personalmente, penso che prendere il secondo approccio ne trarrà beneficio in futuro, ma è difficile lavorare con esso. Sto usando Laravel, un framework PHP. Poiché la maggior parte delle opzioni di "ricerca" sono applicate al veicolo (genitore), piuttosto che alla pubblicità (bambino), è richiesto molto più codice, che sta iniziando a sembrare contro-intuitivo. Lo schema 1 è molto più semplice da utilizzare.

Mi mancano i numerosi vantaggi offerti dallo schema 2? In poche parole, il primo approccio richiede molto meno codice, ma non è relazionale. Il secondo approccio è relazionale, ma richiede molto più codice (e tempo), riducendo la brevità del mio controller di annunci in particolare, che in realtà sta interrogando gli attributi del veicolo più di quelli della pubblicità. Inoltre, rende "difficile" l'ordinamento, in quanto gli utenti possono ordinare "make", "model", "location", "price", ecc. - attributi che saltano tra i modelli.

php relational-database

posta Matthew Ruddy 16.09.2013 - 01:44

fonte

5 risposte

Leggi altre domande sui tag php relational-database

Quale era la necessità di introdurre Python 3 quando avevamo già Python 2 [duplicato] Qual è la corretta informazione sul copyright? [chiuso]

score 5 · Answer 1

La decisione tra la scelta di un modello relazionale rispetto a un modello de-normalizzato è in genere uno di scala e il tipo di operazioni di database che è più probabile che si verifichi.

Generalmente un database relazionale è più facile da interrogare ed è più efficiente per le applicazioni transazionali pesanti, mentre uno schema denormalizzato sarà più appropriato se si pianifica di archiviare un ampio magazzino di dati su cui si prevede di eseguire analisi o report.

Se il tempo è la tua più grande preoccupazione e non credi che questo sito abbia molto traffico a lungo termine, allora scegli assolutamente lo schema 1, ma ti consiglio di documentare il ragionamento alla base della tua decisione finale nel caso in cui qualcun altro possa manterrà il tuo lavoro in futuro e potrebbe essere in difficoltà con una funzionalità che è in contrasto con la tua decisione sullo schema.

Da parte mia, mi prenderei il tempo di renderlo il più possibile relazionale, ma sono un perfezionista.

ProTip : considera l'aggiunta del numero VIN come chiave naturale alla tabella del veicolo. Ti aiuterà a identificare i singoli veicoli e si riferisce a un attributo reale facilmente identificabile di un veicolo reale.

score 3 · Answer 2

Non è una domanda su 1 o 2 tavoli. Prendere in considerazione:

Vehicles Table
-------------------
id            int
make          varchar(255),
model         varchar(255),
..
..

o

Vehicles Table
-------------------
id            int
make          varchar(255),
modelid       int  
..
..


VehicleModel Table
-------------------
modelid       int  
modelname     varchar(255),
..

Un design ben congegnato renderà il tuo database molto più semplice da estendere.

score 2 · Answer 3

La mia regola empirica per tali decisioni è: se il database viene utilizzato come origine di tali dati e i dati vengono mantenuti manualmente in quel database ( OLTP ), mantienilo il più possibile normalizzato, che ti preverrà da un orribile mal di testa in seguito. Dovresti prendere in considerazione di dividerlo in più di 2 tabelle.

Se, tuttavia, i dati non vengono mantenuti in tale db, ma vengono caricati automaticamente da una sorgente diversa e non vengono mai modificati fino a quando il db non viene cancellato (ad esempio, per scopi di reporting o per un OLAP database), dovresti utilizzare la struttura che supporta al meglio i tuoi rapporti, che potrebbe essere la soluzione a un tavolo.

Hai considerato di utilizzare l'approccio a 2 tabelle insieme a una vista unita? La vista potrebbe fornire i dati proprio come lo schema 1, rendendo le tue preoccupazioni su "molto più codice" e "ordinamento complicato" molto probabilmente inutile.

score 0 · Answer 4

Se queste fossero le uniche due opzioni, la prima scelta sarebbe superiore. È quasi certo che ogni annuncio verrà mappato su un solo e unico veicolo; l'unica volta che non è il caso limite in cui qualcuno vende una macchina senza mai immergerla.

Ora, se pratico, potresti ottenere una migliore utilità avendo un tavolo per le pubblicità e uno per determinati modelli di auto: ogni Toyota carolla del 2008 con il pacchetto LX ha le stesse caratteristiche di design, per esempio.

le uniche volte in cui si desidera una relazione uno a uno tra le tabelle è se una tabella è condivisa con un programma diverso o se l'ottimizzazione del database richiede motivi di prestazioni. (e nel secondo caso, la divisione dovrebbe essere nascosta dall'app se possibile).

score 0 · Answer 5

Dovresti usare un RDBMS, nessuna domanda. Il file flat causa dati ridondanti e non è mai una buona cosa. Access, MySQL, My-DB o anche uno su DB di Sun andrebbe bene. Presumo che tu stia utilizzando un DB basato su Oracle per il tuo tavolo. L'accesso sarebbe il migliore e più economico per il desktop e un db basato su Java per il web.