Дизайн хранилища данных для парковки — размеры даты и времени

Я наткнулся на вопрос о практике хранения данных. Я пытался думать о различных способах разработки этого, но я не уверен, каковы лучшие практики. Вопрос касается проектирования хранилища данных для парковки и написания SQL-запроса для получения платы за парковку.

Ограничения следующие:

Почасовая оплата в будние дни

Двухколесный - 1$

Четырехколесный - 2$

Почасовая оплата выходного дня

Двухколесный - 2$

Четырехколесный - 3$

Автомобиль стоит на стоянке с 9 утра пятницы до 10 утра субботы. Создайте хранилище данных для хранения этих данных и напишите SQL, чтобы получить плату за парковку для транспортного средства.

Ниже я мог придумать только два способа его представления:

  • Подход 1

Имея date_id, time_id и тип. Здесь может быть сложно запросить плату за парковку, поскольку у нас нет данных за час. Трудно рассчитать плату за парковку, но потребляет меньше данных

fact_parking_lot_data

fact_keyVehicle_iddate_idtime_idтип
11202205069в
212022050722из
  • Подход 2

Имея date_id, time_id для каждого часа дня. Это создаст несколько записей в таблице фактов для транспортного средства, если транспортное средство припарковано на 2 дня, тогда у него будет 48 записей. Легко рассчитать плату за парковку, но требует много места для хранения

fact_parking_lot_data

fact_keyVehicle_iddate_idtime_id
11202205069
212022050610
312022050611
412022050612
....
....
....
2612022050710

Любые мысли или предложения будут действительно оценены. Благодарю вас !

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
0
17
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Ваша модель является наглядным примером накопительной таблицы моментальных снимков: внешними ключами к измерениям будут Vehicle_id, date_in_id, date_out_id, time_in_id и time_out_id. И как меру продолжительности стоянки.

Когда машина прибывает, заполняются поля date_in_id и time_in_id, но не date_out_id, time_out_id и продолжительность. Когда машина уезжает, заполняются поля date_out_id, time_out_id и продолжительность.

Это дает вам естественную метрику для расчета: общая продолжительность в течение дня или нескольких дней.

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

Если вас не устраивает накапливающийся снимок, то я предпочитаю из двух предложенных вами моделей вторую, где каждый час заполняется, пока машина припаркована.

Теперь несколько замечаний:

  • ваша модель учитывает только часы. Вы можете захотеть, чтобы клавиши времени включали минуты и секунды. Даже если вы не используете его сейчас, он дает вам пространство для роста, если в будущем потребуется минутное и секундное разрешение (конечно, ваша вторая модель становится слишком большой в этой ситуации, поэтому накопление моментального снимка становится очевидным решением).
  • остерегайтесь перехода на летнее время и любых других возможных будущих изменений часового пояса. Если автомобили можно припарковать на ночь и в выходные дни, у вас может быть парковочное мероприятие, которое начинается в субботу в 8 вечера и заканчивается в воскресенье в 8 утра, что фактически длится 11 или 13 часов во время перехода на летнее время. Выберите часовой пояс и придерживайтесь его.
  • добавить location_id. Конечно, может быть, теперь все ваши парковочные события происходят в одном месте, но в будущем могут быть и другие. Лучше включить параметр сейчас и не использовать его, чем добавить его позже.
  • добавить измерение класса транспортного средства. это измерение должно быть SCD типа II с такими атрибутами, как количество колес и цена за единицу. При изменении цены вставляется новая цена за единицу, а управление версиями обеспечивает сохранение истории.

Недостаток накопительного снимка по сравнению с вашей второй моделью (с 1 строкой за период времени): нет простого способа подсчитать, сколько автомобилей припарковано в данный момент времени. Вам придется считать строки во всей таблице фактов, где

(date_in_id < X or (date_in_id = X and time_in_id <= Y)) 
and 
(date_out_id > X or (date_out_id = X and time_out_id > Y)) 

В то время как ваша модель позволяет вам быстро подсчитать, сколько автомобилей припарковано в любой момент, просто подсчитав все автомобили с

date_id = X and time_id = Y

Благодарю вас ! очень помог мне в понимании различных подходов

MJoy 14.05.2022 11:55

Другие вопросы по теме