Progettazione del database per la prima volta:sto esagerando?[Chiuso]

Question

Sfondo

Sono uno studente di informatica al primo anno e lavoro part-time per la piccola impresa di mio padre.Non ho alcuna esperienza nello sviluppo di applicazioni nel mondo reale.Ho scritto script in Python, alcuni corsi in C, ma niente del genere.

Mio padre ha una piccola attività di formazione e attualmente tutte le lezioni sono programmate, registrate e seguite tramite un'applicazione web esterna.Esiste una funzione di esportazione/"report" ma è molto generica e abbiamo bisogno di report specifici.Non abbiamo accesso al database vero e proprio per eseguire le query.Mi è stato chiesto di impostare un sistema di reporting personalizzato.

La mia idea è quella di creare esportazioni CSV generiche e importarle (probabilmente con Python) in un database MySQL ospitato in ufficio ogni notte, da dove posso eseguire le query specifiche necessarie.Non ho esperienza con i database ma capisco le nozioni di base.Ho letto qualcosa sulla creazione di database e sui moduli normali.

Presto potremmo iniziare ad avere clienti internazionali, quindi voglio che il database non esploda se/quando ciò accadrà.Attualmente abbiamo anche un paio di grandi aziende come clienti, con diverse divisioni (ad es.Società madre ACME, divisione sanitaria ACME, divisione bodycare ACME)

Lo schema che ho elaborato è il seguente:

1. Dal punto di vista del cliente:
   • Clienti è la tabella principale
   • I clienti sono collegati al dipartimento per cui lavorano
     • I dipartimenti possono essere sparsi in un paese:Risorse umane a Londra, marketing a Swansea, ecc.
     • I dipartimenti sono collegati alla divisione di un'azienda
   • Le divisioni sono collegate alla società madre
2. Dal punto di vista delle classi:
   • Sessioni è la tabella principale
     • Ad ogni sessione è collegato un insegnante
     • Ad ogni sessione viene assegnato uno statusid.Per esempio.0 - Completato, 1 - Annullato
     • Le sessioni sono raggruppate in "pacchetti" di dimensione arbitraria
   • Ogni pacchetto è assegnato a un cliente

Ho "progettato" (più come scarabocchiato) lo schema su un pezzo di carta, cercando di mantenerlo normalizzato alla terza forma.L'ho quindi collegato a MySQL Workbench e per me è stato tutto carino:
(Clicca qui per la grafica a grandezza naturale)

_{(fonte: maian.org)}

Query di esempio che eseguirò

• Quali clienti con credito ancora rimasto sono inattivi (quelli senza una lezione programmata in futuro)
• Qual è il tasso di partecipazione per cliente/dipartimento/divisione (misurato dall'ID di stato in ciascuna sessione)
• Quante lezioni ha avuto un insegnante in un mese
• Contrassegna i clienti che hanno un basso tasso di partecipazione
• Rapporti personalizzati per i dipartimenti delle risorse umane con i tassi di presenza delle persone nella loro divisione

Domande)

• È un'ingegneria eccessiva o sto andando nella direzione giusta?
• La necessità di unire più tabelle per la maggior parte delle query comporterà un notevole calo delle prestazioni?
• Ho aggiunto una colonna "lastsession" ai client, poiché probabilmente sarà una query comune.È una buona idea o dovrei mantenere il database rigorosamente normalizzato?

Grazie per il tuo tempo

Answer 1

Un po'più di risposte alle tue domande:

1) Sei praticamente sul bersaglio per qualcuno che si sta avvicinando un problema come questo per la prima volta. Credo che i puntatori da altri su questa domanda in tal modo coprono gran lunga praticamente. Buon lavoro!

2 & 3) il calo di prestazioni si prende in gran parte dipenderà da avere e ottimizzare gli indici giusto per le vostre particolari query / procedure e, soprattutto, il volume dei record. A meno che non si sta parlando di ben oltre un milione di record nelle tabelle principali ti sembra di essere sulla buona strada per avere un design abbastanza tradizionale che le prestazioni non sarà un problema su hardware ragionevole.

Detto questo, e questo si riferisce alla tua domanda 3, con l'avvio di avere probabilmente non dovrebbe essere davvero eccessivamente preoccupati per le prestazioni o iper-sensibilità alla normalizzazione dell'ortodossia qui. Si tratta di un server di report che si sta costruendo, non è un'applicazione di backend basato sulle transazioni, che avrebbe un profilo molto diverso rispetto alla importanza delle prestazioni o normalizzazione. Un database sostenere un iscrizione dal vivo e un'applicazione di pianificazione deve essere consapevoli di query che richiedono secondi per restituire i dati. Non solo una funzione di server di report hanno più tolleranza per query complesse e lunghe, ma le strategie per migliorare le prestazioni sono molto diverse.

Per esempio, in un ambiente applicativo basato transazione le opzioni di miglioramento delle prestazioni potrebbero includere il refactoring la stored procedure e delle strutture di tabella all'ennesima potenza, o lo sviluppo di una strategia di caching per piccole quantità di dati comunemente richiesti. In un ambiente di reporting si può certamente fare questo, ma si può avere un impatto ancora maggiore sulle prestazioni con l'introduzione di un meccanismo di un'istantanea in cui un programma viene eseguito il processo e memorizza report preconfigurati e agli utenti di accedere ai dati snapshot senza stress sul livello db su una base per richiesta.

Tutto questo è un rant prolisso per illustrare che cosa principi di progettazione e trucchi si impiegano potrebbero variare dato il ruolo del db che si sta creando. Spero che sia utile.

Answer 2

Hai avuto l'idea giusta. Tuttavia è possibile pulirlo e rimuovere alcuni della mappatura (*) ha tabelle.

Che cosa si può fare è nella tabella Dipartimenti, aggiungere CityId e DivisionId.

Oltre a questo, penso che tutto va bene ...

Answer 3

Le uniche modifiche che farei sono:
1- Cambia il tuo VARCHAR in NVARCHAR, se potresti diventare internazionale, potresti volere unicode.

2- Se possibile, modifica i tuoi ID int in GUID (identificatore univoco) (questa potrebbe essere solo la mia preferenza personale).Supponendo che alla fine arrivi al punto in cui disponi di più ambienti (sviluppo/test/staging/prod), potresti voler migrare i dati dall'uno all'altro.Avere ID GUID rende tutto ciò molto più semplice.

3- Tre livelli per la struttura della tua Azienda -> Divisione -> Dipartimento potrebbero non essere sufficienti.Ora, questo potrebbe essere eccessivo, ma potresti generalizzare quella gerarchia in modo tale da poter supportare n livelli di profondità.Ciò renderà alcune delle tue domande più complesse, quindi potrebbe non valere la pena scendere a compromessi.Inoltre, è possibile che qualsiasi client con più livelli possa essere facilmente "inseribile" in questo modello.

4- Hai anche uno stato nella tabella client che è un VARCHAR e non ha alcun collegamento alla tabella stati.Mi aspetterei un po' più di chiarezza su cosa rappresenta lo stato del cliente.

Answer 4

No. Sembra che si sta progettando ad un buon livello di dettaglio.

Credo che i paesi e le aziende sono in realtà la stessa entità nella progettazione, come sono città e divisioni. Mi piacerebbe sbarazzarsi di paesi e città tavoli (e Cities_Has_Departments) e, se necessario, aggiungere un flag booleano IsPublicSector alla tabella Società (o di una colonna CompanyType se ci sono più scelte rispetto al settore privato semplicemente / Settore pubblico).

Inoltre, penso che ci sia un errore nel vostro utilizzo della tabella Dipartimenti. Sembra che la tabella Dipartimenti serve come riferimento per i vari tipi di reparti che ogni divisione cliente può avere. Se è così, dovrebbe essere chiamato DepartmentTypes. Ma i vostri clienti (che sono, suppongo, i partecipanti) non appartengono a un tipo reparto, appartengono a un'istanza reparto reale in una società. Allo stato attuale, si sa che un determinato cliente appartiene a un reparto risorse umane da qualche parte, ma non quale!

In altre parole, i clienti dovrebbero essere collegati al tavolo che si chiama Divisions_Has_Departments (ma che definirei semplicemente Dipartimenti). Se è così, allora è necessario comprimere Città in Divisioni, come discusso in precedenza, se si desidera utilizzare standard di integrità referenziale nel database.

Answer 5

A proposito, vale la pena notare che, se si sta generando CSV già e vogliono caricarli in un database mySQL, LOAD DATA LOCAL INFILE è il tuo migliore amico: http://dev.mysql.com/doc/refman/5.1/en/load-data.html . Mysqlimport è anche merita di essere esaminata, ed è uno strumento da riga di comando che è fondamentalmente un bel involucro attorno LOAD DATA INFILE.

Answer 6

La maggior parte delle cose sono già state dette, ma sento che posso aggiungere una cosa: è abbastanza comune per gli sviluppatori più giovani a preoccuparsi di prestazioni un po 'troppo up-front, e le tue domande su unendo le tabelle sembra andare in tale direzione. Questo è uno sviluppo di software anti-modello chiamato ' ottimizzazione prematura '. Cercate di bandire quel riflesso dalla vostra mente:)

Ancora una cosa: Credi davvero bisogno le 'città' e le tabelle dei paesi '? Non sarebbe avere una 'città' e la colonna 'paese' nella tabella dipartimenti sufficiente per i vostri casi d'uso? Per esempio. La vostra applicazione ha bisogno di elencare i reparti per città e città a seconda del paese?

Answer 7

A seguito delle osservazioni in base a ruolo di / specialista di reporting di business intelligence e responsabile strategia / pianificazione:

1. Sono d'accordo con la direzione di Larry sopra. IMHO, non è tanto nel corso progettato, alcune cose sembrano un po 'fuori luogo. Per farla semplice, vorrei contrassegnare cliente direttamente ad una società ID, Dipartimento Descrizione, Divisione Designazione, Dipartimento Tipo ID, Divisione Type ID. Usa Dipartimento Tipo ID e divisione tipo ID come riferimenti ad occhiata tabelle e campi di reporting / analisi interne per la coerenza a lungo termine.

2. Packs tabella contiene colonna "Credito", non dovrebbe che in realtà essere legato alla tabella di base client quindi se molti pacchetti si può vedere come credito molto dovuto è rimasto per le classi future? L'applicazione può prendersi cura del calc e conservarla in posizione centrale nella tabella client.

informazioni

3. Società potrebbe utilizzare molti più campi, tra cui l'ovvio indirizzo / telefono / etc. informazione. Mi piacerebbe anche essere preparati per aggiungere in D & B "Duns" colonne (sito / Branch / Ultimate) a lungo termine, Dun and Bradstreet (D & B) ha un enorme catalogo di aziende e troverete più avanti lungo la strada le loro informazioni è molto utile per il reporting / analisi. Questo si prenderà cura del problema divisione multipla si parla, e ti permettono di rimboccarsi le gerarchie per sub / divisione / rami / etc. di grandi corpi.

4. Non accennate quanti record lavorerete con i quali potrebbe implicare insediano per una grande iniziativa di sviluppo che avrebbe potuto essere fatto più velocemente e di gran lunga meno mal di testa con preconfezionate software "reporting". Se il tuo non si tratta di un database di grandi dimensioni (<65000) righe, fare in modo MS-Access, OpenOffice (Base) o affini soluzioni dev rapporto / app non poteva fare il trucco. Io uso il software APEX gratuito di Oracle un bel po 'di me, si tratta con il loro libero database Oracle XE basta scaricarlo dal loro sito.

5. A proposito - Segnalazione intuizione: per le grandi banche dati, in genere si dispone di due istanze di database a) del database di transazione per la registrazione di ogni record dettagliata. b) database di report (data mart / warehouse) realizzato su una macchina separata. Per ulteriori informazioni di ricerca di Google sia Star Schema e Snowflake Schema.

Saluti.

Answer 8

voglio affrontare solo la preoccupazione che l'adesione a mutiple tabelle sarà casue un calo di prestazioni. Non abbiate paura di normalizzare perché si dovrà fare si unisce. Unisce sono normale e previsto in datbases relazionali e sono progettati per gestirli bene. Sarà necessario impostare le relazioni PK / FK (per l'integrità dei dati, questo è importante da considerare nella progettazione), ma in molti database FKS non vengono indicizzati automaticamente. Dal momento che wil essere utilizzati in join, si definitelty vuole iniziare indicizzando il FKS. PKs genere ottenere un indice sulla creazione di come devono essere unici. E 'vero che il design datawarehouse riduce il numero di join, ma di solito uno non arrivare al punto di data warehousing fino a quando uno ha milioni di record necessari per accedere in un unico report. Anche allora magazzini quasi tutti i dati iniziano con un database transazionale per raccogliere i dati in tempo reale e quindi i dati vengono trasferiti al magazzino su un programma (notturno o mensile o qualunque sia la necessità di business è). Quindi questo è un buon inizio, anche se è necessario progettare un data warehouse in seguito per migliorare le prestazioni rapporto.

Devo dire che il vostro disegno è impressionante per uno studente CS primo anno.

Answer 9

Non è over-progettato, questo è come vorrei affrontare il problema. Partecipare è bene, non ci sarà molto di un calo di prestazioni (è del tutto necessaria a meno che non de-normalizzare il database fuori che non è raccomandato!). Per gli stati, vedere se è possibile utilizzare un tipo di dati enum invece di ottimizzare quel tavolo fuori.

Answer 10

Ho lavorato nel campo della formazione / scuola e ho pensato di far notare che c'è in genere una M: 1 rapporto tra ciò che voi chiamate "sessioni" (istanze di un dato ovviamente) e il corso stesso. In altre parole, il vostro catalogo offre il corso ( "Spagnolo 101" o qualsiasi altra cosa), ma si potrebbe avere due diverse istanze di esso durante un singolo semestre (Tu-Th insegnata da Smith, mer-ven insegnata da Jones).

Oltre a questo, sembra che un buon inizio. Scommetto che troverete che il dominio client (grafici che portano a "clienti") è più complessa di quanto tu abbia modellato, ma non esagerare con che fino a quando hai alcuni dati reali per guidare l'utente.

Answer 11

Un paio di cose è venuto in mente:

1. I tavoli sembravano orientati a segnalazione, ma non realmente gestione del business. Vorrei che quando un cliente si iscrive, c'è essenzialmente un ordine di essere immessi per il cliente che frequentano un elenco di sessioni, e che l'ordine potrebbe essere per più dipendenti in una società. Sembrerebbe una tabella di "ordine" sarebbe davvero al centro del sistema e guida la tua acquisizione dati e l'eventuale segnalazione. (Confrontare i documenti cartacei hai utilizzato per eseguire l'attività con la struttura del database per vedere se c'è una corrispondenza logica.)

2. Le aziende spesso non hanno divisioni. I dipendenti a volte cambiano le divisioni / dipartimenti, forse anche metà sessione. Le aziende a volte aggiungere / cancellare / rinominare divisioni / dipartimenti. Assicurarsi che il possibile in tempo reale modificare il contenuto delle tabelle non rende successiva comunicazione / raggruppamento difficile. Con così tanto diviso i dati di contatto in tanti tavoli, potrebbe essere necessario far rispettare molto severa convalida l'immissione dei dati per mantenere i rapporti significativi e inclusiva. Ad esempio, quando viene aggiunto un nuovo cliente, assicurandosi che la sua società / divisione / servizio / città corrispondono gli stessi valori come i suoi colleghi.

3. Il concetto di "pacchetti" non è affatto chiaro.

4. Dato che si indica che è una piccola impresa, sarebbe sorprendente se la prestazione sarebbe un problema, considerando la velocità e la capacità delle macchine attuali.