[MySQL]:vista de tabla o tabla real.(rastreando una clave primaria)

Question

Tengo una Base de Datos que tiene las siguientes relaciones:

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.

Necesito ejecutar una consulta que debe seleccionar una serie de valores de Schedule en función de si Transaction.TimeStamp está dentro de un rango de fechas proporcionado.La consulta debe seleccionar un valor de Programación según su clave principal.La clave principal no se puede rastrear desde la transacción.

Para resolver este problema, he decidido crear una tabla para vincular la Transacción DIRECTAMENTE a la principal del Programa.

Recientemente descubrí Vistas de tabla - ¿Sería esta una situación apropiada para hacer una "vista" de tabla?¿O debería simplemente crear una tabla "real"? TransactionSchedule?

transactionSchedule
Transaction_ID    Schedule_ID

Mi problema es que no entiendo los detalles de cuándo una vista de tabla es útil o cuáles son sus beneficios.

¿Tener una tabla individual para rastrear transacciones->Programar es excesivo?

Realmente agradecería mucho cualquier orientación general sobre este problema.

EDITAR: esta consulta es SÓLO para recuperar datos que ya han sido ingresados

--gracias

Answer 1

Le recomiendo encarecidamente que copie el precio del programa directamente en Compras tan pronto como lo inserte.De esa manera, habrá resuelto su problema y, al mismo tiempo, habrá evitado que más adelante se le cobre un precio diferente al cliente si cambia el horario accidentalmente (o intencionalmente).

En cuanto a lo relacionado con la clave principal del cronograma, y ​​que no se pueda rastrear a partir de una transacción:eso es señal de mal diseño.Quiero decir, piénselo: tiene una marca de tiempo en la transacción, un cronograma, por definición, se coloca en el tiempo usando una marca de tiempo desde y hasta, ¿por qué no puede relacionarlos?AFAICS, la clave principal del cronograma debe ser item_id, from_timestamp, to_timestamp

Suponiendo que su tabla de programación tiene una marca de tiempo desde y hasta, mi consulta sería

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

En cuanto a si debes usar una vista o no, realmente depende de ti.Una vista no funciona mejor ni peor que una consulta, la única diferencia es que la definición se almacena en la base de datos.Las principales ventajas de eso son

• las personas pueden reutilizar la definición sin copiar la consulta (y estropearla), la
• puede cambiar el esquema hasta cierto punto y ocultarlo de la aplicación siempre que actualice la vista en consecuencia (esta última ventaja a menudo se sobreestima)

Answer 2

No se puede tener el registro de la transacción una clave externa vinculada con la clave primaria horario? o se trata de una relación de muchos a muchos. De cualquier manera, no veo vista según el caso aquí.