[MySQL]: табличное представление или фактическая таблица. (отслеживание первичного ключа)

Question

У меня есть база данных, которая имеет следующие отношения:

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.

Мне нужно выполнить запрос, который должен выбрать серию значений из расписания, если Transaction.TimeStamp находится в пределах указанного диапазона дат. Запрос должен выбрать значение из расписания на основе его первичного ключа. Первичный ключ не прослеживается из транзакции.

Чтобы решить эту проблему, я решил создать таблицу, чтобы НЕПОСРЕДСТВЕННО связать транзакцию с первичным объектом расписания.

Недавно я обнаружил Табличные представления - это будет подходящей ситуацией для создания таблицы "представление"? Или мне просто создать «фактическую» таблицу TransactionSchedule?

transactionSchedule
Transaction_ID    Schedule_ID

Моя проблема в том, что я не понимаю специфику, когда представление таблицы полезно / каковы преимущества.

Имеет ли отдельная таблица Trace Transaction-> Schedule overkill?

Действительно, любые общие рекомендации по этой проблеме будут высоко оценены.

РЕДАКТИРОВАТЬ : Этот запрос предназначен ТОЛЬКО для получения данных, которые уже были введены

- спасибо

Answer 1

Я настоятельно призываю вас скопировать цену из графика прямо в «Покупку», как только вы вставите ее. Таким образом, вы решили свою проблему и в то же время не допустили, чтобы клиенту впоследствии была назначена другая цена, если вы случайно (или намеренно) изменили график.

Что касается связи с первичным ключом расписания, и это невозможно отследить от перехода: это признак плохого замысла. Я имею в виду, подумайте об этом - у вас есть временная метка в транзакции, график по определению размещается во времени с использованием меток от и до - почему вы не можете связать их? AFAICS, первичный ключ расписания должен быть item_id, from_timestamp, to_timestamp

Предполагая, что ваша таблица расписания имеет метку времени от и до Мой запрос будет

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

Что касается того, использовать ли вам представление или нет - на самом деле, решать вам. Представление не работает лучше или хуже запроса, единственное отличие состоит в том, что определение хранится в базе данных. Основными преимуществами этого являются

• люди могут повторно использовать определение, не копируя запрос (и не испортив его),
• вы можете изменить схему до некоторой степени и скрыть ее от приложения, если вы соответствующим образом обновите представление (последнее преимущество часто переоценивается)

Answer 2

Может ли запись транзакции иметь внешний ключ, связанный с первичным ключом расписания? или это отношения многие ко многим. В любом случае я не вижу здесь подходящего представления.