Tryck och parkera:En datamodell för parkeringsappar

Olika appar lovar att göra ditt sökande efter parkering smärtfritt. Låt oss undersöka den här typen av appar med våra datamodelleringsglasögon. Hur ser den underliggande modellen ut?

I en tidigare artikel förklarade vi hur en parkeringsplats är uppbyggd och hur en datamodell kan utformas för att hantera en. I den här artikeln undersöker vi datamodellen för en parkeringsapp. Du känner till dessa appar:de listar närliggande parkeringsalternativ, berättar priserna och låter dig boka eller reservera en plats eller köpa ett parkeringskort.

Denna applikation gör ditt sökande efter parkering relativt smärtfritt. Jag skulle säga att den viktigaste faktorn för att välja en parkeringsplats är priset. En fem minuters promenad som sparar några kronor är alltid värt det. Med det sagt, låt oss ta på oss våra datamodelleringsglasögon och ta en närmare titt på världen av parkeringsappar.

Vad bör vi veta om parkeringsplatser och parkeringsappar?

Parkeringsappar är ganska enkla:vi kan förvänta oss funktioner för att spåra tillgängligheten och priset på parkeringsplatser i realtid, boka nämnda platser och betala avgifterna.

Bortsett från platsen, som är relativt lätt för en datamodellerare att hantera, är nyckelfaktorn för parkeringsplatser priset. Prisstrategin för parkeringsplatser är ganska okomplicerad och vissa metoder eller regler är praktiskt taget universella:

Parkeringsplatser har ofta olika priser för olika tider. En dag är vanligtvis indelad i tre delar – morgon (6:00 till 11:00), middag (11:00 till 17:00) och kväll (17:00 till 22:00).
Kvällar och morgnar har vanligtvis högre priser, eftersom fler bilar sannolikt behöver plats under dessa timmar.
Priser kan också variera beroende på veckodagar. Till exempel kommer en parkeringsplats nära en stadskärna att debitera mer på helgen (lördag och söndag) eftersom det är då fler människor besöker.
För det mesta använder många sina standardpriser. Det finns dock dagar då de kan ta mer betalt – t.ex. Parkeringsplatser nära basebollarenor kan ta mer betalt när det är en match eller ett evenemang på arenan.
Parkeringsplatser nära transportnav (flygplatser, järnvägsstationer och busshållplatser) kan tillåta parkering under 24 timmar om dygnet eller en vecka. De kommer sannolikt att ha ett specialpris för långtidsparkering.
Vissa parkeringsplatser utfärdar månadskort till en fast kostnad. Månadskortinnehavare betalar det fasta beloppet varje månad istället för att betala en daglig avgift.

Datamodellen

Som du kan se finns det tre ämnesområden:

"Parkeringsplats"
"Kund"
"Parkeringsbokning"

Låt oss ta det viktigaste ämnesområdet först – det som hanterar parkeringsplatser och deras prissättning.

Parkeringsplats

Detta ämnesområde kretsar kring parking_lot tabell, som lagrar information om varje parkeringsplats i vårt system. Den här tabellen förklaras grundligt i vår tidigare artikel om en datamodell för hantering av parkeringsplatser. Vi kommer dock att upprepa några viktiga kolumner här:

zip – Ett postnummer; detta spelar en stor roll i sökfunktionen.
is_slot_available – Uppdaterad av parkeringsoperatörer och indikerar om det finns plats för närvarande.
is_reentry_allowed – Om en kund kan parkera igen på tomten efter att de lämnat den. Om återinträde inte är tillåtet måste den återkommande kunden köpa ett annat utrymme.
is_valet_parking_available – Betjänad parkering kostar extra, men folk föredrar det ofta – speciellt när de är på dejt. 😉
operational_in_night – Om parkeringen är öppen på natten. Denna information blir mycket viktig när din bil står parkerad nära en flygplats och ditt flyg kommer in vid midnatt!
minimum_hr_pay – Minimiavgiften för att parkera din bil på en tomt. Till exempel har vissa tomter ett minimum på tre timmar, vilket innebär att du betalar för tre timmar även om du bara är parkerad i 30 minuter.
is_monthly_pass_allowed –Om många erbjuder månadskort.

Vi har redan diskuterat de faktorer som spelar in vid fastställandet av parkeringspriser. Låt oss nu se hur vi hanterar prissättningen i vår modell. Vi använder parking_pricing tabell för att hålla ett register över vanliga priser och pricing_exception tabell för att registrera eventuella undantag. Båda tabellerna har en liknande struktur och kolumnerna är självförklarande. De enda skillnaderna är:

parking_pricing tabellen har en kolumn (day_of_week ) som lagrar den veckodag som är relevant för ett pris. pricing_exception tabellen har ett calendar_date kolumn som innehåller det faktiska datumet då specialpriset gällde.
När appen visar priser visas pricing_exception tabellen har företräde framför parking_pricing tabell. Så om det vanliga priset för idag är 5 USD i timmen men det finns ett specialpris på 7 USD, kommer appen att visa 7 USD per timme.

Finalbordet i detta ämnesområde är offers . Den har register över rabattkuponger och deras tillhörande detaljer. Vi har förklarat datamodellen bakom erbjudanden, erbjudanden och rabatter i en tidigare artikel. Den här tabellen är baserad på samma teori, och alla kolumner bör vara självförklarande.

Kund

När vi tänker på en parkeringsapp tänker vi vanligtvis på dessa tre element:

Kunder – Detta inkluderar ett unikt kund-ID och grundläggande information om appanvändare, som deras namn och telefonnummer. Det skulle också vara bra att ha deras faktureringsadress.
Fordon – En person kan ha flera bilar, så vi borde ha förmågan till en en-till-många-relation mellan en appanvändare och deras fordon. Självklart skulle vi behöva ett sätt att identifiera fordon, till exempel genom deras licensnummer.
Betalningsmetoder – Eftersom den här applikationen tillåter kunder att reservera en parkeringsplats och betala för den, behöver vi ett sätt att lagra betalningsmetoder. Återigen borde det finnas ett sätt att ha flera betalningsmetoder per användare.

Denna modell har en tabell för var och en av dessa enheter. customer_id attributet refereras till i vehicle och payment_method tabeller; den länkar användare till fordon och betalningsmetoder.

Parkeringsbokning

Detta ämnesområde innehåller bara två tabeller. Av de två lagrar tabellen "parking_one_time_reservation" reservationsinformation. Några av dess kolumner är självförklarande; de andra är:

start_timestamp – Datum och tid då bokningsperioden börjar.
pay_for_min_hr – Innehåller ett 'N' om reservationen är för ett visst antal timmar (t.ex. från 09:00 till 12:00). Annars kommer det här attributet att ha ett "Y".
booking_for_hr – Antal timmar för en bokning. Detta är ett nullbart fält; det kommer att ha ett värde endast när pay_for_min_hr är inställd på 'N'. I exemplet ovan skulle den vara inställd på "3" för de tre timmar som förflyter mellan kl. 09.00 och middagstid.
basic_parking_cost – Den grundläggande parkeringskostnaden, i lokal valuta.
offer_code – En eventuell kupongkod. Eftersom det är valfritt att använda en erbjudandekod och är beroende av tillgänglighet, är denna kolumn nullbar.
net_cost – Det faktiska belopp som kunderna betalar i kassan (när de lämnar tomten).
is_paid – Om parkeringsavgifter har betalats. Detta blir en viktig kolumn när återinträde tillåts på samma parkeringssedel. I sådana fall regleras betalningarna vanligtvis vid första kassan (dvs första gången bilen lämnar tomten).

parking_monthly_pass Tabellen registrerar information om alla månadskort som utfärdas till kunder via denna applikation. Månadskort kan köpas när som helst, även för framtida datum. Så vi har två separata kolumner, purchase_date och start_date , som gör det möjligt för appanvändare att köpa pass som är giltiga i framtiden. De andra kolumnerna är självförklarande.

Vad mer kan vi lägga till i parkeringsappens datamodell?

Moderna parkeringsplatser är utrustade med alla typer av tekniker, som registreringsskyltläsare, sensorer, automatiska parkeringskontrollsystem och smarta parkeringsmätare. Dessa avancerade system gör parkeringsplatser lättare att köra och enklare för bilister att använda.

Vilka ytterligare ändringar behöver denna datamodell för att stödja fullt utrustade parkeringsplatser? Berätta för oss vad du tycker i kommentarsfältet.