sfondo

Sono uno studente CS del 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 degli 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 effettivo per eseguire le query. Mi è stato chiesto di impostare un sistema di segnalazione personalizzato.

La mia idea è quella di creare le 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 nei database ma capisco le basi. Ho letto un po 'sulla creazione di database e forme normali.

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

Lo schema che ho escogitato è il seguente:

1. Dal punto di vista del cliente:
   • I clienti è il tavolo principale
   • I clienti sono collegati al dipartimento per cui lavorano
     • I dipartimenti possono essere sparsi in un paese: risorse umane a Londra, marketing in Swansea, ecc.
     • I dipartimenti sono collegati alla divisione di una società
   • Le divisioni sono collegate alla società madre
2. Dal punto di vista delle lezioni:
   • Sessioni è la tabella principale
     • Un insegnante è collegato ad ogni sessione
     • Uno statusid viene assegnato a ciascuna sessione. Ad esempio 0 - Completato, 1 - Annullato
     • Le sessioni sono raggruppate in "pacchetti" di dimensioni arbitrarie
   • Ogni pacchetto è assegnato a un client

Ho "disegnato" (più come scarabocchiato) lo schema su un pezzo di carta, cercando di mantenerlo normalizzato nella terza forma. L'ho quindi inserito in MySQL Workbench e mi ha reso tutto molto carino:
( Fai clic qui per un elemento grafico a dimensioni intere )

_{(fonte: maian.org )}

Query di esempio che eseguirò

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

Domande)

• È troppo ingegnoso o sto andando nella direzione giusta?
• La necessità di unire più tabelle per la maggior parte delle query determinerà un grande successo in termini di prestazioni?
• Ho aggiunto una colonna "lastession" ai clienti, poiché probabilmente sarà una query comune. È una buona idea o devo mantenere il database strettamente normalizzato?

Grazie per il tuo tempo

Qualche altra risposta alle tue domande:

1) Sei praticamente sul bersaglio per qualcuno che sta affrontando un problema come questo per la prima volta. Penso che i suggerimenti degli altri su questa domanda finora la coprano praticamente. Buon lavoro!

2 e 3) Il successo che subirai dipenderà in gran parte dall'avere e dall'ottimizzazione degli indici giusti per le tue particolari richieste / procedure e, soprattutto, il volume dei record. A meno che tu non stia parlando di oltre un milione di record nelle tue tabelle principali, sembra che tu sia sulla buona strada per avere un design sufficientemente mainstream che le prestazioni non saranno un problema su hardware ragionevole.

Detto questo, e questo si riferisce alla tua domanda 3, con l'inizio che hai probabilmente non dovresti davvero preoccuparti eccessivamente delle prestazioni o dell'ipersensibilità all'ortodossia di normalizzazione qui. Questo è un server di report che stai creando, non un back-end basato su transazioni, che avrebbe un profilo molto diverso rispetto all'importanza delle prestazioni o della normalizzazione. Un database che supporta un'applicazione di registrazione e pianificazione in tempo reale deve tenere conto delle query che richiedono secondi per restituire i dati. Non solo una funzione del server di report ha una maggiore tolleranza per query complesse e lunghe, ma le strategie per migliorare le prestazioni sono molto diverse.

Ad esempio, in un ambiente applicativo basato sulle transazioni, le opzioni di miglioramento delle prestazioni potrebbero includere il refactoring delle procedure memorizzate e le strutture delle tabelle all'ennesima potenza o lo sviluppo di una strategia di memorizzazione nella cache per piccole quantità di dati comunemente richiesti. In un ambiente di reportistica puoi certamente farlo ma puoi avere un impatto ancora maggiore sulle prestazioni introducendo un meccanismo di snapshot in cui viene eseguito un processo pianificato e memorizza report preconfigurati e gli utenti accedono ai dati di snapshot senza stress sul tuo livello db su una base per richiesta.

Tutto questo è una lunga propensione per illustrare che quali principi di progettazione e trucchi che utilizzi possono differire dato il ruolo del db che stai creando. Spero sia utile.

Hai l'idea giusta. Puoi comunque ripulirlo e rimuovere alcune delle tabelle di mappatura (ha *).

Quello che puoi fare è nella tabella Dipartimenti, aggiungere CityId e DivisionId.

Oltre a ciò, penso che tutto vada bene ...

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

2- Se possibile, modifica i tuoi ID int in GUID (uniqueidentifier) ​​(questa potrebbe essere solo la mia preferenza personale). Supponendo che alla fine arrivi al punto in cui hai più ambienti (dev / test / staging / prod), potresti voler migrare i dati dall'uno all'altro. Gli ID GUID lo rendono notevolmente più semplice.

3- Tre livelli per la tua azienda -> Divisione -> La struttura del dipartimento potrebbe non essere sufficiente. Ora, questo potrebbe essere un eccesso di ingegneria, ma potresti generalizzare quella gerarchia in modo tale da poter supportare livelli di profondità n. Questo renderà alcune delle tue domande più complesse, quindi potrebbe non valere il compromesso. Inoltre, è possibile che qualsiasi client con più livelli possa essere facilmente "impacchettabile" in questo modello.

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

No. Sembra che tu stia progettando con un buon livello di dettaglio.

Penso che i Paesi e le Aziende siano davvero la stessa entità nel tuo design, così come le Città e le Divisioni. Mi sbarazzerei delle tabelle di Paesi e Città (e Cities_Has_Departments) e, se necessario, aggiungerei una bandiera booleana IsPublicSector alla tabella Companies (o una colonna CompanyType se ci sono più opzioni rispetto al semplice settore privato / settore pubblico).

Inoltre, penso che ci sia un errore nell'utilizzo della tabella Dipartimenti. Sembra che la tabella Dipartimenti serva da riferimento ai vari tipi di dipartimenti che ogni divisione clienti può avere. In tal caso, dovrebbe essere chiamato DepartmentTypes. Ma i tuoi clienti (che sono, presumo, partecipanti) non appartengono a un dipartimento TIPO, appartengono a un'istanza di reparto effettiva in un'azienda. Così com'è ora, saprai che un determinato cliente appartiene a un reparto risorse umane da qualche parte, ma non quale!

In altre parole, i clienti dovrebbero essere collegati alla tabella che si chiama Divisions_Has_Departments (ma che chiamerei semplicemente Dipartimenti). In tal caso, è necessario comprimere le città in divisioni come discusso sopra se si desidera utilizzare l'integrità referenziale standard nel database.

A proposito, vale la pena notare che se stai già generando CSV e vuoi caricarli in un database mySQL, LOAD DATA LOCAL INFILE è il tuo migliore amico: http://dev.mysql.com/doc/refman/5.1/ it / load-data.html . Anche Mysqlimport merita di essere esaminato, ed è uno strumento da riga di comando che è sostanzialmente un buon wrapper per il caricamento dei dati.

Molte cose sono già state dette, ma sento che posso aggiungere una cosa: è abbastanza comune per gli sviluppatori più giovani preoccuparsi un po 'troppo delle prestazioni in anticipo, e la tua domanda sull'unione dei tavoli sembra andare in quella direzione. Questo è un anti-modello di sviluppo software chiamato ' Ottimizzazione precoce '. Prova a bandire quel riflesso dalla tua mente :)

Ancora una cosa: credi di aver davvero bisogno delle tabelle "città" e "paesi"? Una colonna "città" e "paese" nella tabella dei dipartimenti non sarebbe sufficiente per i tuoi casi d'uso? Ad esempio, l'applicazione deve elencare i dipartimenti per città e città per paese?

Seguenti commenti basati sul ruolo di Business Intelligence / Reporting Specialist e responsabile della strategia / pianificazione:

1. Sono d'accordo con la direzione di Larry sopra. IMHO, non è molto ingegnerizzato, alcune cose sembrano un po 'fuori posto. Per semplicità, taggerei il cliente direttamente su un ID azienda, descrizione reparto, descrizione divisione, ID tipo reparto, ID tipo divisione. Utilizzare l'ID del tipo di reparto e l'ID del tipo di divisione come riferimenti alle tabelle di ricerca e ai campi di reporting / analisi interni per coerenza a lungo termine.

2. La tabella dei pacchetti contiene la colonna "Credito", non dovrebbe in realtà essere legata alla tabella di base del Cliente, quindi se hanno molti pacchetti puoi vedere quanto credito è dovuto per le classi future? L'applicazione può occuparsi del calc e archiviarlo centralmente nella tabella Client.

3. Le informazioni sull'azienda potrebbero utilizzare molti più campi, incluso l'indirizzo / telefono / ecc. Ovvio. informazione. Sarei anche pronto ad aggiungere nelle colonne "DUN" di D&B (Site / Branch / Ultimate) a lungo termine, Dun e Bradstreet (D&B) hanno un enorme catalogo di società e scoprirai in seguito lungo la strada che le loro informazioni sono molto utili per report / analisi. Questo risolverà il problema della divisione multipla che menzionerai e ti permetterà di arrotolare la loro gerarchia per sub / divisione / filiali / ecc. di grandi corpi.

4. Non menzionate quanti record con cui lavorerete, il che potrebbe implicare la preparazione di una grande iniziativa di sviluppo che avrebbe potuto essere fatta più rapidamente e molti meno mal di testa con il software di "reporting" preconfezionato. Se non hai a che fare con un database di grandi dimensioni (<65000), assicurati che MS-Access, OpenOffice (Base) o le relative soluzioni di sviluppo report / app non possano fare il trucco. Io uso il software APEX gratuito di Oracle un po 'da solo, viene fornito con il loro database gratuito Oracle XE, basta scaricarlo dal loro sito.

5. Cordiali saluti - Analisi dei report: per database di grandi dimensioni, in genere sono disponibili due istanze di database a) database di transazioni per la registrazione di ogni record dettagliato. b) database di report (data mart / data warehouse) ospitati su una macchina separata. Per ulteriori informazioni, cerca su Google sia Star Schema che Snowflake Schema.

Saluti.

Voglio affrontare solo la preoccupazione che unirmi alle tabelle multiple determinerà un successo nelle prestazioni. Non abbiate paura di normalizzare perché dovrete fare join. I join sono normali e previsti nei database relazionali e sono progettati per gestirli correttamente. Sarà necessario impostare relazioni PK / FK (per l'integrità dei dati, questo è importante da considerare nella progettazione) ma in molti database gli FK non vengono automaticamente indicizzati. Dal momento che verranno utilizzati nei join, sarà sicuramente necessario iniziare indicizzando l'FKS. I PK generalmente ottengono un indice alla creazione in quanto devono essere unici. È vero che la progettazione del datawarehouse riduce il numero di join, ma di solito non si arriva al punto di immagazzinamento dei dati fino a quando non si ha accesso a milioni di record in un report. Anche in questo caso quasi tutti i data warehouse iniziano con un database transazionale per raccogliere i dati in tempo reale e quindi i dati vengono spostati nel magazzino secondo una pianificazione (notturna o mensile o qualunque sia la necessità aziendale). Quindi questo è un buon inizio anche se è necessario progettare un data warehouse in un secondo momento per migliorare le prestazioni dei report.

Devo dire che il tuo design è impressionante per uno studente CS del primo anno.

Non è troppo ingegnerizzato, è così che affronterei il problema. L'adesione va bene, non ci sarà un grande impatto sulle prestazioni (è completamente necessario a meno che non si de-normalizzi il database che non è raccomandato!). Per gli stati, vedere se è possibile utilizzare un tipo di dati enum invece di ottimizzare quella tabella.

Ho lavorato nel campo della formazione / scuola e ho pensato di sottolineare che esiste generalmente una relazione M: 1 tra ciò che chiamate "sessioni" (istanze di un determinato corso) e il corso stesso. In altre parole, il tuo catalogo offre il corso ("Spanish 101" o altro), ma potresti avere due diversi casi durante un singolo semestre (Tu-Th, tenuto da Smith, Mer-Ven, tenuto da Jones).

A parte questo, sembra un buon inizio. Scommetto che scoprirai che il dominio client (grafici che portano ai "clienti") è più complesso di quello che hai modellato, ma non esagerare con questo fino a quando non avrai alcuni dati reali per guidarti.

Mi sono venute in mente alcune cose:

1. I tavoli sembravano orientati alla rendicontazione, ma non gestivano realmente l'attività. Penserei che quando un cliente si iscrive, c'è essenzialmente un ordine che viene effettuato per il cliente che frequenta un elenco di sessioni e quell'ordine potrebbe essere per più dipendenti in una società. Sembrerebbe che una tabella di "ordine" sia davvero al centro del tuo sistema e favorisca l'acquisizione dei dati e l'eventuale reportistica. (Confronta i documenti cartacei che hai utilizzato per gestire l'azienda con il design del tuo database per vedere se c'è una corrispondenza logica.)

2. Le aziende spesso non hanno divisioni. I dipendenti a volte cambiano divisioni / dipartimenti, forse anche a metà sessione. Le aziende a volte aggiungono / eliminano / rinominano divisioni / dipartimenti. Assicurati che l'eventuale modifica in tempo reale dei contenuti delle tue tabelle non renda difficili i successivi rapporti / raggruppamenti. Con così tanti dati di contatto suddivisi su così tante tabelle, potresti dover applicare una convalida molto rigorosa dell'immissione dei dati per mantenere i tuoi rapporti significativi e inclusivi. Ad esempio, quando viene aggiunto un nuovo cliente, assicurandosi che la sua azienda / divisione / dipartimento / città corrisponda agli stessi valori dei suoi colleghi.

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

4. Dato che indichi che è una piccola impresa, sarebbe sorprendente se le prestazioni fossero un problema, considerando la velocità e la capacità delle macchine attuali.