Non progettare il database prima. Se sembra scoraggiante cercare di capire tutte le variabili e le tabelle che ti serviranno in base allo schema iniziale, è un segno che potresti essere avvicinando il problema da sbagliato direttamente.
Invece, progetta il tuo database quando hai qualcosa da memorizzare , in particolare qualcosa che vorresti riassumere o interrogare per quest'ultimo. Potresti scoprire che basta scrivere JSON o XML su disco poiché i file di testo saranno tutto ciò di cui hai bisogno. In alternativa, è possibile memorizzare un BLOB XML o JSON per ogni routine e consentire che le routine vengano interrogate, aggiunte e riepilogate. Oppure, potresti scoprire che XML e JSON sono più problemi che valgono, e in realtà hai solo bisogno di alcune tabelle relazionali.
Se hai già scaricato l'applicazione client e vuoi lavorare su un server database che memorizzerà tutte le informazioni per i client di un centro fitness, procedi come segue:
- Identifica ciò che deve essere effettivamente elencato e interrogato . Come ho accennato prima, se non hai intenzione di eseguire una query sui dati grezzi, una serializzazione JSON o XML degli oggetti dati in Java potrebbe essere la soluzione migliore. (Ricorda che, se il file è troppo grande per rientrare in una
CHAR , puoi sempre memorizzare il testo in un campo "memo" o "blob", a seconda del tuo database.)
- Cerca informazioni ripetute , dove più di un singolo campo può essere collegato insieme in qualche oggetto dedotto, ovvero sposta due o più campi in una tabella separata che avrebbe un numero pari a -una relazione con la loro provenienza. Quello che hai elencato nella domanda è un buon inizio, anche se potresti trovare di più o scoprire che hai reso il tuo schema troppo complesso.
- Per ogni tabella, determina una chiave univoca corretta che sarà immutabile e unica per tutti i record. Non aver paura di creare chiavi virtuali tramite identità o meccanismi simili. E non ossessionare ancora le prestazioni; se una chiave naturale sembra migliore di una chiave virtuale, vai avanti e usala.
- Assegna a ogni campo e tabella un nome chiaro e distinto. I nomi delle chiavi devono essere univoci in tutto il database, anche se i campi secondari non devono essere necessariamente. (Anche se, naturalmente, non c'è nulla di male nel vederli così.)
- Con tutto quanto precede, fai un progetto iniziale del database . Vuoi ottenere alcune tabelle in cui puoi inviare alcuni dati di esempio e compilare alcuni buoni dati di test.
- Una volta terminato il database, codifica il livello di accesso ai dati della tua applicazione, che legge i dati nel modulo nativo dell'app e invia detto modulo nativo in un modo che il database può accettare.
- Dopo che hai funzionato il codice e puoi scrivere dati appropriati e recuperare i record che ti aspettavi, carica il tuo database di sviluppo con dati di esempio . Questo può essere completamente fittizio o informazioni dai beta tester o una combinazione di entrambi. Sentiti libero di buttare lì dati di alcuni anni di dati attesi. O altro.
- Con un database le cui tabelle contengono alcuni dati sostanziosi, ottimizza il database . Potrebbe essere necessario aggiungere o regolare le chiavi, ridimensionare alcune tabelle in viste normalizzate o modificare i tipi di dati di alcuni campi. I numeri e la testabilità sono tuoi amici e dovrebbero essere la tua guida.
Non aver paura se ti ritrovi a fare un passo indietro, oa metterli fuori uso. Mantenere il database come fornitore indipendente dal punto di vista dei costi, quindi, se necessario, è possibile passare da SQLite a MonoDB a MSSQL come richiesto dal progetto.
Bonus Rant
Qualunque cosa tu faccia, e non posso sottolineare questo abbastanza se non hai familiarità con i database relazionali, TENERE LE TAVOLE NARROW . Non aggiungere campi come set1Reps e set2Reps alla stessa tabella; questo è un mal di testa di un odore di codice e un enorme segno che dovresti avere un campo XML o JSON interno per archiviare i dati asimmetrici o sottotabelle chiare e distinte.
Se per qualche motivo ti trovi a desiderare un recordset molto ampio in modo da poterlo semplicemente scorrere tra i suoi campi e assegnarli a un singolo oggetto di dati, puoi sempre farlo tramite una Vista e qualche SQL intelligente. Ma in tal caso, saresti molto più bravo con la serializzazione e la non serializzazione di molti dei tuoi oggetti dati.
