Organizzare feste per bambini non è un compito facile:tutto deve essere perfettamente pianificato e consegnato. Altrimenti succede il caos. Spetta agli adulti, in particolare agli organizzatori di feste, occuparsi di tutto e farlo correttamente.
C'è un modo migliore per farlo che organizzare tutto in un database? Non pensiamo così!
Le feste per bambini variano molto. Alcuni sono semplici, come feste di compleanno che includono solo inviti, cibo (spuntini, bevande e una torta) e magari un clown o un mago per intrattenere i bambini. Gli altri partiti sono molto più complessi. Potrebbero richiedere una gita fuori porta, posti letto e molte altre attività. Più la festa è complicata, meno spazio per gli errori. Anche se un clown che è in ritardo di 10 minuti non è un grosso problema, nessuno vuole aspettare con un gruppo di ragazzi annoiati un autobus con due ore di ritardo!
Vediamo cosa può fare un modello di dati per aiutare gli organizzatori di feste a rimanere organizzati.
Di cosa abbiamo bisogno nel nostro modello di dati?
Supponiamo di gestire un'attività di pianificazione di feste. Avremo un elenco di servizi che offriamo ai clienti. Questi servizi potrebbero essere forniti da noi, oppure potremmo avvalerci di partner (es. assumiamo il clown).
Combiniamo questi servizi e li offriamo ai clienti come pacchetto festa. Ogni pacchetto ha un punto di inizio e di fine o un programma. Ciò include non solo la festa stessa, ma anche l'organizzazione della festa e la pulizia successiva. Potremmo anche avere più sedi (ad es. una festa inizia con una pizza al ristorante, quindi si sposta in spiaggia per nuotare).
Dovremo anche mettere in relazione le attività con i dipendenti, tenere traccia dei progressi delle parti e addebitare i nostri servizi. Vediamo come si fa.
Il modello di dati per le feste dei bambini
Il nostro modello di dati sulle feste per bambini è composto da quattro aree tematiche:
Countries & citiesPartners & servicesEmployees & rolesParty
Presenteremo ogni area tematica nello stesso ordine in cui è elencata.
Sezione 1:Paesi e città
Questa area tematica contiene solo due tabelle. Non sono specifici per questo modello, ma li utilizzeremo in altre aree tematiche.
Possiamo aspettarci di operare in più città e forse anche in diversi paesi. Pertanto, dovremo fare riferimento a varie città. Questo ci aiuterà a tracciare dove si trovano le parti e anche quali servizi offriamo in ciascuna sede.
Il country il dizionario contiene solo il country_name UNICO valore. Per ogni city , memorizzeremo la combinazione UNICA di postal_code – city_name – country_id .
Sezione 2:Partner e servizi
Successivamente, analizziamo in dettaglio i servizi che forniremo ai nostri clienti.
Un elenco di tutti i servizi possibili è memorizzato nel service dizionario. Contiene solo il service_name UNICO attributo.
In questo modello di dati, tutti i servizi sono forniti dai partner. Anche quando la nostra azienda fornisce effettivamente il servizio, la tratteremo come un partner servizio (e noi siamo il partner). Il dizionario dei partner memorizzerà tutti i partner con cui lavoriamo, inclusi noi. Per ogni partner, memorizzeremo un partner_name UNICO . I details memorizza tutti i dettagli aggiuntivi relativi a quel partner utilizzando un formato non strutturato o strutturato (ad es. utilizzando coppie nome-valore separate da un separatore predefinito).
Il provides table è il tavolo finale e più importante di questa sezione. Per ogni record, memorizzeremo:
partner_id– Ilpartnerche fornisce un servizio.service_id– Ilservicequesto partner fornisce.city_id– Fa riferimento allacitydove questo servizio è fornito da quel partner.date_from– La data in cui il partner ha iniziato a offrire quel servizio.date_to– La data in cui il partner ha smesso di offrire quel servizio. Questo valore potrebbe essere NULL se la relazione partner di servizio è ancora in corso.details– Tutti i dettagli aggiuntivi relativi a quel servizio, come la descrizione del servizio, il prezzo, ecc. Possiamo aspettarci che tutti i dettagli saranno in un formato testuale strutturato, utilizzando coppie chiave-valore.
La combinazione di partner_id – service_id – city_id – date_from forma la chiave UNICA in questa tabella. Quando inseriamo un nuovo record, dobbiamo controllare che non si sovrapponga a nessun record esistente.
Sezione 3:Dipendenti e ruoli
Prima di passare alla parte centrale e più importante del nostro modello, dobbiamo guardare le tabelle relative ai nostri dipendenti e ai loro ruoli.
La tabella centrale in questa area tematica è il employee tavolo. Per ogni dipendente, memorizzeremo il suo first_name , last_name , user_name e password . Utilizzeranno questi ultimi due attributi per accedere alla nostra applicazione.
Un elenco di tutti i ruoli possibili è memorizzato nel role dizionario. Ogni ruolo è UNICAMENTE definito dal suo role_name . I ruoli sono correlati alle azioni che ogni dipendente compie durante una festa. Pertanto, possiamo aspettarci valori come "party manager" o "assistente" qui.
I ruoli possono essere assegnati ai dipendenti tramite il has_role tavolo. Il employee_id – role_id coppia indicherà i ruoli attivi che ogni dipendente ha in quel momento.
Sezione 4:Festa
Il Party l'area tematica è la parte centrale di questo modello. Lo useremo per mettere in relazione tabelle di altre aree tematiche e avremo anche alcune nuove informazioni qui.
Il tavolo centrale qui è il party tavolo. Per ogni festa, memorizzeremo:
city_id– Lacitydove si svolgerà la festa.client_id– Ilclientquesta festa è organizzata per.details– Una descrizione testuale dettagliata della parte.start_time_plannedeend_time_planned– L'ora che abbiamo programmato per questa festa, inclusa la configurazione e la pulizia.start_time_actualeend_time_actual– I tempi effettivi della festa (e dei relativi servizi).price_offered– Il prezzo che abbiamo quotato per organizzare questa festa per questo cliente.time_offered– Quando è stata fatta l'offerta.price_paid– L'importo effettivo pagato dal cliente per questa parte.time_paid– Quando è stato effettuato il pagamento.
Ogni parte è collegata a un cliente. Abbiamo già fatto riferimento al client tabella, ma ora vedremo cosa è memorizzato lì. Sono andato solo con i dati di base:client_name , dettagli di contatto (address , email , phone , mobile ), ed eventuali dettagli aggiuntivi in formato testuale.
Ciascuna parte avrà anche un elenco di servizi ad essa associati. Tale elenco è archiviato nel service_included tavolo. Per ogni record, avremo bisogno di:
party_id– Fa riferimento alla relativaparty.service_id– Fa riferimento alserviceinclusi nella festa.provides_id– Fa riferimento alproviderdi tale servizio, nonché del servizio stesso. Questo attributo può essere NULL, poiché lo aggiorneremo quando selezioniamo il provider specifico.details– Eventuali dettagli testuali aggiuntivi relativi a quel servizio in quella parte.start_time_plannedeend_time_planned– Gli orari pianificati in cui il servizio dovrebbe essere fornito durante la festa.
Dovremo anche tenere traccia dei progressi di ciascuna festa. Useremo due tabelle per farlo.
Lo status la tabella elencherà tutti i possibili stati che potrebbero essere assegnati a un party. Per ogni record, memorizzeremo un status_name UNICO e tre flag:
successful– È andato tutto bene? O ci sono stati problemi con i nostri servizi?paid– La festa è stata pagata?final– È questo lo stato finale di questa festa?
Assegneremo stati ai servizi aggiungendo nuovi record a party_status tavolo. Per ogni record, memorizzeremo i riferimenti alla party e service tabelle e il timestamp quando questo stato è stato assegnato.
Il tavolo finale nel nostro modello è la invoice tavolo. Non è specifico per questo modello, ma abbiamo bisogno di una struttura di base per archiviare le fatture. Per ogni fattura, registreremo:
client_name– Il nome del cliente al momento dell'emissione della fattura.party_id– Ilpartyrelativi a questa fattura.client_id– L'ID delclientin fase di fatturazione.invoice_amount,discount,vat_amount,total_amount– I dettagli finanziari della fattura.time_issued- Quando questa fattura è stata emessa o aggiunta al database.time_paid- Quando questa fattura è stata pagata.
Cosa faresti con questo modello di dati?
Questo modello è piuttosto semplice, ma vedo diversi modi in cui possiamo migliorarlo. Quali modifiche proporresti? C'è qualcosa che potremmo organizzare diversamente? Forse dobbiamo aggiungere o rimuovere una funzione. Per favore, diccelo nei commenti.
