Lasciami parlare per esperienza personale: questa è un'idea eccezionale che rimpiangeresti di fare .
Excel non è semplicemente un buon strumento per database. Solo alcuni dei motivi:
- Quasi impossibile disporre di sistemi appropriati per le autorizzazioni (che gli utenti possono visualizzare / modificare dati specifici.) Almeno utilizzare xlVeryHidden se si utilizza questa route per la "scheda dati" principale). Dovrai creare molte finestre di dialogo personalizzate o gestire blocchi molto complicati / frustranti. Questo è un incubo.
- Non è progettato per essere un database. Sono fogli di calcolo. Fare query / etc su di esso può essere fatto (puoi scrivere SQL vs fogli di calcolo se
odi la tua vita vuoi) ma perché? Ci sono tanti strumenti migliori, progettati appositamente per questo scopo.
- Le cartelle di lavoro condivise sono un disastro in attesa di accadere quando molte persone le aggiornano frequentemente
- Non modella facilmente la logica della tabella con query / viste
- Ogni vista dati dovrà essere creata su misura (non ha la semplice logica di tabella / query che Access fa, ad esempio. Puoi creare maschere / viste molto più facilmente con una logica TON più espansa che in Excel)
Queste ragioni sono ulteriormente aggravate dal fatto che esistono molti strumenti (come Access) progettati specificamente per fornire funzionalità semplici per fare tutto ciò che si vuole fare con un database.
this is as much about me gaining experience in designing/implementing software as it is about the end result
Stai chiedendo informazioni più dettagliate su come scrivere software. Se sei un carpentiere che cerca di imparare a mettere le unghie in una tavola, non userai una sega - userai un martello, una pistola sparachiodi, ecc.
Cercare di fare questa applicazione in Excel equivale a usare una sega per imparare a inchiodare. Potrebbe funzionare, certo. Ma in realtà non imparerai come mettere le unghie in una tavola in modo giusto .
I've come up with a new structure and I wanted to know, is it a good structural model or do I need to abstract the data into more layers?
Qui ci sono due risposte.
In primo luogo, se si desidera utilizzare Excel, si vuole effettivamente ridurre a icona quanto ben progettato lo schema del database. Quando si progetta un database, lo si vuole normalizzare il più possibile. Tuttavia con Excel, in realtà non si vuole fare questo, perché crea un incubo per l'effettiva implementazione. Si desidera utilizzare le ricerche di intervallo e quindi disporre di un singolo foglio per tutte le ricerche. In un database queste sarebbero tabelle con chiavi esterne.
In secondo luogo, vorrei strongmente suggerire di guardare in Microsoft Access per quello che stai facendo. Farà in modo che questo processo di progettazione vada dall'essere insanamente frustrante / complicato a molto semplice. Per quel percorso:
A unique ID consisting of their index concatenated with the CaseItem ID E.G. Case ID = #00000001, Step 12 ID = #00000001,#12
Questo è il genere di cose che Excel ti farà fare. Poiché stai pensando in un foglio di calcolo, il concetto di chiave univoca non ha senso per te (dal momento che vedrai "il chiave).
Se invece usi un vero programma di database puoi farlo:
CaseItem table
- Unique ID
- Misc information
- CurrentProcessStep
ProcessStep table (for definition of process steps. these items can be reused)
- Unique ID
- Misc information (description / etc)
CaseProcessSteps table (matches processsteps to caseitems
- CaseItemID
- ProcessStepID
- Date related items
Potresti anche avere una tabella separata per le informazioni sulla data, se lo desideri.
Questo è più simile a un database. Non un foglio di calcolo. Rappresentare quanto sopra in un foglio di calcolo ottiene veramente concettualmente perché se lo fai in questo modo, hai bisogno di una query per rappresentare i dati in formato "leggibile" - poiché usa tutti gli ID (come un database dovrebbe ) ma Excel non riesce per quello. Puoi fare una query SQL o un gruppo di index / match / vlookups, ma questa è una cosa hacky completa.
Questo tipo di installazione è banale da implementare in Access. È anche un milione di volte più facile creare viste appropriate per inserire / modificare queste informazioni in Access che Excel ..