Hai bisogno di aiuto nello sviluppo della logica DB

Questo è un mini-progetto del mio – Sistema di prenotazione aerea – consente di chiamare questa compagnia aerea FlyMi: Ho un database (Non ho deciso quale, mio ​​amico vuole andare con MongoDB).

Anyhoo, questo è il mio requisito: ho un tavolo con i dettagli del volo – numero di volo, programma, ecc. Userò questa tabella per eseguire varie operazioni – prenotazione, cancellazione, modifica

È qui che sono bloccato: per l’app desktop e l’applicazione Web, offro un’opzione per selezionare i posti. Ciò significa che devo tenere traccia di quali posti sono prenotati, quali no. E supponiamo di avere un’interfaccia utente, che mostra i posti come
Rosso – prenotato
Verde – Non prenotato.

E tutto questo – per ogni volo. La mia domanda è: quale pensi sia il modo più efficiente per tenere traccia delle prenotazioni dei posti, per ogni volo in quella compagnia aerea?

Idea attuale: mantieni un tavolo chiamato passeggero – con tutti i dettagli come nome, indirizzo ecc. Che tengono traccia di tutti i passeggeri e mantieni un ID passeggero in modo tale che i primi 4 caratteri siano ID del volo, Ultimo 2 caratteri sono numeri di posto che hanno scelto, con un numero casuale intermedio (dico casuale perché penso che sia immateriale qui). Quindi, per qualsiasi volo, se devo scoprire il numero di posti non prenotati, dovrò scansionare tutti i passeggeri, chi ha prenotato e chi ha prenotato in quel volo. Penso che questo sia davvero inefficiente. Forniscimi la logica più efficiente per farlo.

Non usare “chiavi intelligenti”.

Questa è una ctriggers idea chiamata “smart keys” o “encoding information in keys”.

Vedi questa risposta che contiene questo estratto :

Nonostante sia facile da implementare una Smart Key, è difficile consigliarne di crearne uno che non sia una chiave naturale, perché tendono a finire nei guai, a prescindere dai loro vantaggi, perché rende più difficili i database per refactoring, impone un ordine che è difficile da modificare e potrebbe non essere ottimale per le query, richiede un confronto tra stringhe se la Smart Key include caratteri non numerici ed è meno efficace di una chiave composita nell’aiutare le aggregazioni basate su intervalli. Inoltre, viola la linea guida relazionale di base che ogni colonna dovrebbe memorizzare valori atomici

Le Smart Keys tendono anche a superare i loro limiti di codifica originali

(Si noti che le posizioni dei sedili sono generalmente identificate dalle smart key in quanto sono un numero di riga e un conteggio su una riga, ma sono anche tipicamente fissate fisicamente in modo permanente in quella formazione e immaginano se siano state etichettate e riorganizzate).

Informati sulla progettazione del database.

Descrivi la tua attività nei termini più semplici. Ecco come funzionano i database dei modelli relazionali e i DBMS.

Trova abbastanza modelli di frase per riempire il campo in bianco [nome-] per descrivere le tue situazioni lavorative:

"customer [cid] has name [firstname] [lastname] AND customer [cid] has a phone number [phonenumber] of type [type] ..." "customer [cid] can use credit card #[card_no]" "seat [seatid] is at row [row] and column [column]" "seat [seatid] is booked" "seat [seatid] is temporarily committed to an unfinished booking" ... 

Per ogni tale modello di frase parametrizzato (alias predicato ) esiste una tabella di base in cui i nomi degli spazi / parametri sono nomi di colonne. Ogni riga di una tabella afferma che la proposizione ( proposizione ) ottenuta dal riempimento degli spazi vuoti per i suoi valori di colonna; ogni riga non in una tabella afferma NON la dichiarazione dal compilare gli spazi vuoti per i suoi valori di colonna.

Quindi per ogni tabella trova tutte le dipendenze funzionali (FD) che detengono. (Quando un predicato può essere express nella forma “… AND column = F ( column1 , …)” allora diciamo che la colonna set { column1 , …} determina funzionalmente la colonna colonna e che FD set → tiene la colonna .) Quindi identificare ogni chiave candidato (CK). (Un superkey è un set di colonne che determina in modo funzionale ogni colonna. Cioè che è univoco , vale a dire dove ogni sottotitoli di valori per quelle colonne appare solo in una riga di un tavolo.Un CK è un superkey che non contiene un superkey più piccolo. ) Quindi trova tutte le dipendenze di join (JD). (Alcuni predicati dicono “… AND …” per un certo numero di AND e “…” s. Esiste una JD quando la tabella per ogni predicato “…” assomiglia a quello che ottieni dal prendere solo le sue colonne dalla tabella originale). Si noti che ogni FD viene fornito con un JD (binario) associato.

Quindi normalizza le tue tabelle in quinta forma normale (5NF). Questo significa decomporre (cioè sostituire una tabella in cui JD “… AND …” tiene per tabelle i cui predicati sono i “…” s) fino a quando ogni JD che detiene è implicito dai CK (cioè deve mantenere quando il I JD dei FD dei CK sono in attesa.) (Per motivi di prestazioni si può anche denormalizzare combinando le tabelle di base che non sono in 5NF).

Vedi questa risposta e questa .

Quindi interrogiamo descrivendo le righe che vogliamo. Lo facciamo collegando i predicati della tabella di base con operatori logici (cioè AND, OR, NOT, FOR AOME, PER TUTTI, ecc.) E le chiamate di funzione per fornire i predicati per le tabelle che vogliamo e / o collegando i nomi delle tabelle di base tramite operatori di relazione ( cioè JOIN, UNION, MINUS / EXCEPT, PROJECT / SELECT, RENAME / AS) per dare i valori delle tabelle che vogliamo e / o entrambi (es. RESTRICT / WHERE).

Il JOIN di due tabelle contiene le righe che fanno una vera dichiarazione, cioè ha come predicato, l’AND dei loro predicati; e l’UNIONE l’OR, il MINUS / EXCEPT di AND NOT; e che le colonne PROJECT / SELECT di una tabella inseriscono FOR SOME tutte le altre colonne prima del suo predicato; e RESTRICT / WHERE pone AND condition dopo il suo predicato; e il RENAME / AS della colonna rinomina tale parametro nel suo predicato. Pertanto, un’espressione di tabella corrisponde a un predicato: un valore di tabella (tabella di base o risultato di una query) contiene le righe che costituiscono un’istruzione vera dal relativo predicato (della tabella di base o dell’espressione di query).

Vedi questa risposta

Lo stesso vale per i vincoli , che sono affermazioni vere che descrivono collettivamente le situazioni dell’applicazione e gli stati del database rispetto a quelle che possono sorgere date le situazioni che possono sorgere e i predicati della tabella di base.

Vedi questa risposta