[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

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

Является ли наличие отдельной таблицы для отслеживания транзакций->запланирования излишним?

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

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

--Спасибо

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

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