Progettazione del database con problemi di prestazioni e utilizzo delle viste

Is it really a big performance issue to make multiple tables with unique columns. I have heard indexing columns help quite a lot?

Dipende dal sistema DB. Quasi ogni sistema di DB relazionale che conosco automaticamente aggiungerà un indice per le chiavi primarie. Alcuni sistemi DB aggiungono anche indici automaticamente per ogni vincolo FK, altri no. Per le colonne di chiavi esterne da utilizzare in JOINS, ha molto senso aggiungere un indice in anticipo e dovresti controllare il manuale del tuo DB come si comporta quando si creano nuovi vincoli FK.

In realtà, le prestazioni dipendono anche dall'aspetto delle istruzioni selezionate, un classico "JOIN" dovrebbe far sì che la maggior parte dei DB utilizzi l'indice, ma l'aggiunta di alcune logiche complesse alle istruzioni select può interrompere la capacità dei DB di utilizzare l'indice. Per il tuo sistema scolastico, non sprecherei troppi pensieri in questo finché non subirai alcun reale problema di prestazioni.

Are views helpful in maintaining the relational database and making the queries faster?

Inoltre, questo dipende dal sistema DB. Alcuni di loro hanno un meccanismo per la cache o le viste di indicizzazione, altri no. Vedi questo post SO per una discussione dettagliata su, ad esempio, MS SQL Server. Se vuoi davvero saperlo, provalo e misura. Nella tua situazione, non introdurrei nessun punto di vista per risolvere problemi di prestazioni "ipotetici". Vorrei solo presentare le viste se ti aiuta a semplificare alcune delle tue query.

And in table c I have not used separate primary key id because I want to make sure that the one student can borrow one item at a time. Is this a good practice?

Per assicurarti che uno studente possa prendere in prestito un articolo alla volta, dovresti usare un unico contrappeso sugli ID combinati per studenti e articoli. Questo non ha molto a che fare con l'aggiunta di una chiave primaria separata (che può essere fatta, o no, ci sono buone ragioni a favore e contro farlo, ma nel tuo caso, non mi aspetto che faccia una grande differenza). / p>     

I sistemi DB sono veloci. A meno che tu non stia facendo qualcosa come il portale web di molte scuole per usare il tuo software sulla stessa piattaforma, di solito non dovresti avere problemi con un normale HW (purché tu generi le query in un modo un po 'sano di mente).

Detto questo, se hai ancora dei dubbi non è così difficile creare uno script che popolerà il tuo database con centinaia o migliaia di professori, dozzine di professori e argomenti, ecc. Qui puoi testare la tua piattaforma e decidere se davvero bisogno di passare il tempo a "sintonizzare" il modello (la mia scommessa è che non sarà necessario).

In generale, si raccomanda di evitare l'ottimizzazione prematura. Puoi terminare di usare giorni e settimane di sforzi per aggiornare qualcosa che andava bene per cominciare. Se si progetta bene il proprio sistema (vg, un livello di programmazione che astrae l'accesso ai dati), se in seguito nello sviluppo si riscontrano problemi di prestazioni, è possibile eseguirli senza dover modificare gran parte del proprio sistema.

Inoltre, per quanto riguarda

3.And in table c I have not used separate primary key id because I want to make sure that the one student can borrow one item at a time. Is this a good practice

"Uno studente può prendere in prestito un oggetto" è una regola aziendale. In tal caso, il preside potrebbe venire da te e dire "hey, ora gli permettiamo di prendere in prestito due oggetti". Preparerei il modello per consentire N prestiti e applicare il "solo articolo" nel codice (forse anche con una classe separata per controllare le restrizioni, consente di scambiare rapidamente la classe quando necessario).

Ho hackerato un esempio di base con Mysql Workbench in 5 minuti

Puoiaverediversimetodiperteneretracciadeiprestitipresiinprestitoerestituiti,homostratounesempioconborrow_historyperconservarelacronologiaetupuoigestireselibrary_itemssonofuorionotramiteilcampo"borrowed_until". Puoi anche tenere traccia di quanti libri uno studente ha tirato fuori "in prestito", che puoi + = 1 su prestito e - = 1 al ritorno.

Puoi confrontarlo con Schema database Wordpress e vedere quanto è piccolo lo schema del tuo database.

Nondevipreoccupartitroppodelloschemafinchénoncolpisciqualchemilionedirighe,equindicorreggeregliindicisiprenderàcuradellamaggiorpartedellecoseperte.Sediventimoltopiùgrande,potrestiprovareaprovarealcunesoluzioniNosqlintandem.

Provaaverificarealcunelogichedibusinesschehaimenzionatonellatuaapplicazione,farlosuldatabasepuòesserepiùdifficileepotrebberichiederel'apprendimentodistoredprocedure,trigger,ecc.Pensochesarebbeutileperimpararequellidopoavermasterizzatoloschemadeldatabasetecnichediprogettazioneeindicizzazione.

Puoipreoccupartidimoltecose,ma"l'ottimizzazione prematura è la radice di tutti i mali". I join non saranno un problema fino a quando non diventerai pazzo, forse fino a 10 join per una query che potrebbe iniziare a causare problemi. Ma se il tuo database è piccolo, non importa. Ovviamente devi indicizzare le chiavi esterne, ma presumo che tu lo sapresti. L'unico modo per capire queste cose è creare dati falsi e verificare come si comportano.

1 - non dovrebbe essere un problema finché non raggiungi milioni di righe. In generale si dovrebbe iniziare con uno schema "logico" pulito e cambiarlo quando e si verifica un problema di prestazioni.

2 - Le viste sono solo "sql in scatola" che interrogano una vista non è diversa dall'esecuzione dell'SQL sottostante. Ci sono buoni motivi per usare le viste ma le prestazioni non sono tra queste.

3 - Fino a voi davvero, dipende dalle vostre esigenze. (Ma il tuo esempio mostra un id :-))

Penso che sia una buona idea prendere in considerazione le prestazioni della query all'inizio della fase di progettazione, ma a un certo punto il database deve contenere i dati richiesti dall'applicazione. Anche se il design della tua tabella non è ottimale, puoi cambiarlo in un secondo momento (più facile a dirsi), migliorare l'indicizzazione, i risultati delle query cache (diversi database offrono le proprie soluzioni), creare tabelle denormalizzate che contengono risultati del rapporto precalcolato / unito, aggiungi altro hardware.

Is it really a big performance issue to make multiple tables with unique columns. I have heard indexing columns help quite a lot?

Ad un certo punto il collegamento di molte tabelle causerà un problema di prestazioni; tuttavia penso che sia più di 4. L'indicizzazione aiuterà. A un certo punto troppi indici limiteranno le prestazioni sulle modifiche dei dati perché tutti questi indici devono essere mantenuti. Poiché questo è per un sistema scolastico e i corsi degli studenti cambiano con ogni termine, è possibile archiviare termini passati, quindi questo database potrebbe non crescere così tanto. Nessuno sta andando a dare un'occhiata a un libro per un corso su cui hanno lavorato lo scorso anno.

Are views helpful in maintaining the relational database and making the queries faster?

Non proprio. Sono solo un oggetto nel database che contiene tutto il testo per la tua query. È necessario progettare query ad alte prestazioni indipendentemente da dove sono archiviate. Può rendere più facile il riutilizzo, ma attenzione, avendo più livelli di visualizzazione (una vista di una vista di una vista) danneggerà le prestazioni nella maggior parte degli RDBMS. I database non riutilizzano il codice e altre lingue.

And in table c I have not used separate primary key id because I want to make sure that the one student can borrow one item at a time. Is this a good practice?

È ancora possibile utilizzare una chiave primaria separata insieme a un altro vincolo univoco. Poiché ti affidi a questo vincolo univoco per soddisfare questo requisito, se devi includere o escludere un'altra / e colonna / e, non devi modificare le relazioni con altre tabelle o eventualmente doverle ricostruire. Al momento non stai facendo affidamento su questo per unirti a un altro tavolo.