[MySQL]: vista tabella o tabella effettiva. (Tracciando una chiave primaria)

Question

Ho un database che ha le seguenti relazioni:

Transaction->Purchase->Item->Schedule

Transaction - self explanitory
Purchase - any purchase info that relates to the item being purchased (quantity, if the user purchases more than one item).  A given Transaction can have more than one Purchase_ID tied to it.
Item - Stores Item info and relates it to individual clients.
Schedule - determines the price of an item at a given time of day.

Ho bisogno di eseguire una query che deve selezionare una serie di valori da Schedule basate su se Transaction.TimeStamp è all'interno di una data-range in dotazione. La query ha bisogno di selezionare un valore da Schedule basa su di essa la chiave primaria. La chiave primaria non è rintracciabile da transazione.

Per risolvere questo problema, ho deciso di creare una tabella di collegare transazione direttamente al primario di pianificazione.

Di recente ho scoperto Tabella Visualizzazioni - questo sarebbe una situazione adeguata per fare un tavolo "vista"? O devo solo creare un 'reale' tavolo TransactionSchedule?

transactionSchedule
Transaction_ID    Schedule_ID

Il mio problema è che non capisco le specifiche di cui una vista tabella è utile / quali sono i vantaggi.

Sta avendo un tavolo individuo a Trace Transaction-> Pianifica eccessivo?

In realtà tutti gli orientamenti generali di questo problema sarebbe molto apprezzato.

Modifica : è solo per il recupero dei dati che è già stato inserito questa query

- grazie

Answer 1

Vorrei vivamente di copiare il prezzo dal programma direttamente di acquisto, non appena si sta inserendo questo. In questo modo, hanno risolto il problema, e, allo stesso tempo, impedito di un prezzo diverso di essere a carico del cliente in seguito, se accidentalmente (o intenzionalmente) modifica la pianificazione.

Per quanto riguarda relative alla chiave primaria della tabella di marcia, e questo non essendo tracciabile da un transation: che è un segno di cattiva progettazione. Voglio dire, pensateci - si dispone di un timestamp in un'operazione, una pianificazione per definizione, è collocato nel tempo utilizzando una da e per timestamp - perché non puoi metterli in relazione? AFAICS, chiave primaria della tabella di marcia dovrebbe essere item_id, from_timestamp, to_timestamp

Assumendo che il tavolo ha un programma da e per timestamp La mia domanda sarebbe

SELECT     ..your columns..
FROM       Transaction t
INNER JOIN Purchase    p
ON         t.id        = p.transaction_id
INNER JOIN Item        i
ON         p.id        = i.purchase_id
INNER JOIN Schedule    s
ON         i.id        = s.item_id
AND        t.timestamp BETWEEN s.from_timestamp
                           AND s.to_timestamp

Per quanto riguarda, si dovrebbe usare una vista o no - in realtà, tocca a voi. Un punto di vista non funziona meglio o peggio di una query, l'unica differenza è che la definizione viene memorizzata nel database. I principali vantaggi di questo sono

• la gente può riutilizzare la definizione senza copiare la query (e scompigliare in su), il
• è possibile modificare lo schema in una certa misura e nascondere che dall'applicazione purché si aggiorna la vista di conseguenza (quest'ultimo vantaggio è spesso sovrastimato)

Answer 2

Non è possibile il record delle transazioni avere una chiave esterna collegata con la chiave primaria programma? o è una relazione molti-a-molti. Ad ogni modo non vedo vista come appropriato qui.