[MySQL]:представление таблицы или фактическая таблица.(отслеживание первичного ключа)
-
22-09-2019 - |
Вопрос
У меня есть база данных, которая имеет следующие отношения:
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
Моя проблема в том, что я не понимаю специфики того, когда табличное представление полезно/каковы его преимущества.
Является ли наличие отдельной таблицы для отслеживания транзакций->запланирования излишним?
Действительно, любое общее руководство по этой проблеме будет высоко оценено.
РЕДАКТИРОВАТЬ: этот запрос предназначен ТОЛЬКО для получения уже введенных данных
--Спасибо
Решение
Я настоятельно рекомендую вам скопировать цену из списка непосредственно в раздел «Покупки», как только вы ее вставите.Таким образом, вы решили свою проблему и в то же время предотвратили взимание другой цены с клиента в дальнейшем, если вы случайно (или намеренно) измените расписание.
Что касается первичного ключа расписания, и это не отслеживается из транзакции:это признак плохого дизайна.Я имею в виду, подумайте об этом: у вас есть временная метка в транзакции, расписание по определению размещается во времени с использованием временной метки «от» и «до» — почему вы не можете связать их?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
А вот использовать представление или нет — на самом деле, решать вам.Представление не работает лучше или хуже запроса, разница лишь в том, что определение хранится в базе данных.Основными преимуществами этого являются
- люди могут повторно использовать определение, не копируя запрос (и не испортив его),
- вы можете в некоторой степени изменить схему и скрыть ее от приложения при условии соответствующего обновления представления (последнее преимущество часто переоценивается)
Другие советы
Разве запись транзакции не может иметь внешний ключ, связанный с первичным ключом расписания?или это отношения «многие ко многим».В любом случае, я не считаю здесь подход уместным.