Tryk og parker:En parkeringsapp-datamodel

Forskellige apps lover at gøre din søgen efter parkering smertefri. Lad os undersøge denne type app ved hjælp af vores datamodelleringsbriller. Hvordan ser den underliggende model ud?

I en tidligere artikel forklarede vi, hvordan en parkeringsplads er opbygget, og hvordan en datamodel kan designes til at administrere en. I denne artikel undersøger vi datamodellen for en parkeringsapp. Du kender disse apps:De viser parkeringsmuligheder i nærheden, fortæller dig priserne og lader dig bestille eller reservere en plads eller købe et parkeringskort.

Denne applikation gør din søgen efter parkering relativt smertefri. Jeg vil sige, at den vigtigste faktor ved valg af parkeringsplads er prisen. En fem-minutters gåtur, der sparer et par penge, er altid det værd. Når det er sagt, lad os tage vores datamodelleringsbriller på og se nærmere på verden af parkeringspladsapps.

Hvad bør vi vide om parkeringspladser og parkeringsapps?

Parkeringsapps er ret enkle:Vi kan forvente funktioner til at spore tilgængeligheden og prisen på parkeringspladser i realtid, booking af nævnte pladser og betaling af gebyrer.

Bortset fra placeringen, som er relativt nem for en datamodeller at håndtere, er den vigtigste drivkraft for parkeringspladser prisen. Prisstrategien for parkeringspladser er ret ligetil, og visse metoder eller regler er praktisk talt universelle:

Parkeringspladser har ofte forskellige priser på forskellige tidspunkter. En dag er almindeligvis opdelt i tre dele – morgen (6:00 til 11:00), middag (11:00 til 17:00) og aften (17:00 til 22:00).
Aften og morgen har normalt højere priser, da flere biler sandsynligvis har brug for plads i disse timer.
Priser kan også variere baseret på ugedagene. For eksempel vil en parkeringsplads nær en bymidte opkræve mere i weekenden (lørdag og søndag), fordi det er når flere mennesker besøger.
Det meste af tiden bruger partier deres standardpriser. Der er dog dage, hvor de kan opkræve mere – f.eks. parkeringspladser i nærheden af baseballstadioner kan opkræve mere, når der er en kamp eller begivenhed på stadion.
Parkeringspladser i nærheden af transportknudepunkter (lufthavne, banegårde og busholdepladser) kan tillade parkering i 24-timers døgn eller en uge. De vil sandsynligvis have en særlig pris for længerevarende parkering.
Nogle parkeringspladser udsteder månedskort til en fast pris. Indehavere af månedskort betaler det faste beløb hver måned i stedet for at betale en daglig afgift.

Datamodellen

Som du kan se, er der tre emneområder:

"Parkeringsplads"
"Kunde"
"Parkeringsreservation"

Lad os tage det vigtigste fagområde først - det, der håndterer parkeringspladser og deres prissætning.

Parkeringsplads

Dette emneområde drejer sig om parking_lot tabel, som gemmer detaljer om hver parkeringsplads i vores system. Denne tabel er grundigt forklaret i vores tidligere artikel om en parkeringspladsstyringsdatamodel. Vi vil dog gentage et par vigtige kolonner her:

zip – Et postnummer; dette spiller en stor rolle i søgefunktionen.
is_slot_available – Opdateret af parkeringspladsoperatører og angiver, om der er ledig plads i øjeblikket.
is_reentry_allowed – Om en kunde kan parkere igen på pladsen, efter at de har forladt den. Hvis genindtastning ikke er tilladt, bliver den tilbagevendende kunde nødt til at købe en anden plads.
is_valet_parking_available – Parkeringsservice koster ekstra, men folk foretrækker det ofte – især når de er på date. 😉
operational_in_night – Om parkeringspladsen er åben om natten. Disse oplysninger bliver meget vigtige, når din bil er parkeret i nærheden af en lufthavn, og dit fly kommer ind ved midnat!
minimum_hr_pay – Minimumsgebyr for at parkere din bil på en grund. For eksempel har nogle grunde et minimum på tre timer, hvilket betyder, at du betaler for tre timer, selvom du kun er parkeret i 30 minutter.
is_monthly_pass_allowed –Om en masse tilbyder månedskort.

Vi har allerede diskuteret de faktorer, der indgår i fastsættelsen af parkeringspriser. Lad os nu se, hvordan vi håndterer prissætning i vores model. Vi bruger parking_pricing tabel for at holde en fortegnelse over almindelige priser og pricing_exception tabel for at registrere eventuelle undtagelser. Begge tabeller har en lignende struktur, og kolonnerne er selvforklarende. De eneste forskelle er:

parking_pricing tabellen har en kolonne (day_of_week ), der gemmer den ugedag, der er relevant for en pris. pricing_exception tabellen har en calendar_date kolonne, der indeholder den faktiske dato, hvor den særlige pris var gældende.
Når appen viser priser, er pricing_exception tabellen har forrang over parking_pricing bord. Så hvis den almindelige pris for i dag er 5 USD i timen, men der er en særlig sats på 7 USD, viser appen 7 USD i timen.

Finalebordet i dette emneområde er offers . Det opbevarer optegnelser over rabatkuponer og deres tilhørende detaljer. Vi har forklaret datamodellen bag tilbud, tilbud og rabatter i en tidligere artikel. Denne tabel er baseret på den samme teori, og alle kolonnerne bør være selvforklarende.

Kunde

Når vi tænker på en parkeringsapp, tænker vi normalt på disse tre elementer:

Kunder – Dette inkluderer et unikt kunde-id og grundlæggende detaljer om appbrugere, såsom deres navn og telefonnummer. Det ville også være godt at have deres faktureringsadresse.
Køretøjer – Én person kan have flere biler, så vi burde have mulighed for et en-til-mange forhold mellem en app-bruger og deres køretøjer. Vi har naturligvis brug for en måde at identificere køretøjer på, f.eks. ved deres licensnummer.
Betalingsmetoder – Da denne applikation giver kunderne mulighed for at reservere en parkeringsplads og betale for den, har vi brug for en måde at gemme betalingsmetoder på. Endnu en gang burde der være en måde at have flere betalingsmetoder pr. bruger på.

Denne model har én tabel for hver af disse enheder. customer_id attribut refereres til i vehicle og payment_method borde; det forbinder brugere til køretøjer og betalingsmetoder.

Parkeringsreservation

Dette emneområde indeholder kun to tabeller. Af de to gemmer tabellen "parking_one_time_reservation" reservationsdetaljer. Nogle af dens spalter er selvforklarende; de andre er:

start_timestamp – Datoen og tidspunktet, hvor reservationsperioden starter.
pay_for_min_hr – Indeholder et 'N', hvis reservationen er for et bestemt antal timer (f.eks. fra kl. 9.00 til middag). Ellers vil denne attribut have et 'Y'.
booking_for_hr – Antallet af timer for en reservation. Dette er et nullbart felt; det vil kun have en værdi, når pay_for_min_hr er sat til 'N'. I eksemplet ovenfor ville den være indstillet til "3" for de tre timer, der går mellem kl. 9.00 og middag.
basic_parking_cost – De grundlæggende parkeringsomkostninger i lokal valuta.
offer_code – En eventuel kuponkode. Da anvendelse af en tilbudskode er valgfri og afhængig af tilgængelighed, er denne kolonne nullbar.
net_cost – Det faktiske beløb, som kunderne betaler ved kassen (når de forlader partiet).
is_paid – Om der er betalt parkeringsafgift. Dette bliver en vigtig spalte, når genadgang er tilladt på samme parkeringsseddel. I sådanne tilfælde afregnes betalinger normalt ved første kasse (dvs. første gang bilen forlader pladsen).

parking_monthly_pass tabel registrerer oplysninger om alle månedlige pass udstedt til kunder gennem denne applikation. Månedskort kan til enhver tid købes, også til fremtidige datoer. Så vi har to separate kolonner, purchase_date og start_date , der gør det muligt for appbrugere at købe kort, der er gyldige i fremtiden. De øvrige kolonner er selvforklarende.

Hvad andet kan vi tilføje til parkeringsappens datamodel?

Moderne parkeringspladser er udstyret med alle slags teknologier, såsom nummerpladelæsere, sensorer, automatiserede parkeringsadgangskontrolsystemer og smarte parkeringsmålere. Disse avancerede systemer gør parkeringspladser nemmere at køre og nemmere for bilister at bruge.

Hvilke yderligere ændringer har denne datamodel brug for for at understøtte fuldt udstyrede parkeringspladser? Fortæl os venligst dine tanker i kommentarfeltet.