Certo, ma uno dei vantaggi di avere tutto in locale è proprio quello della velocità. In caso lo mettessi in rete in futuro di può fare in modo che le immagini delle copertine non vengano caricate tutte insieme per non sovraccaricare la cache, ma richiamane una solo quando si apre la scheda del libro in questione.
In locale le immagini le dovrai caricare comunque, avranno comunque un peso.
In merito alla rete però no, non dovresti fare così: l'approccio corretto sarebbe innanzitutto comprimerle. Ma era solo un esempio, potrei anche fartene un altro: se hai un algoritmo che fa 2 cicli innestati, è comunque "non efficiente", al di là che tu lo scriva in C++ o in altro.
Posto che sul Web chiaramente potresti usare altri linguaggi, come Go ad esempio. Ma sarà un problema che ti porrai a tempo debito. ?
Ma se io inserissi nel software desktop la richiesta di una chiave di licenza, che il software confronta con quelle memorizzate in un database in rete sarebbe più difficile il crack, almeno credo.
Quindi lo limiteresti al solo utilizzo online? Si, puoi anche farlo.
Considera però che dipende come lato codice vai a fare il controllo. Ipotizzando che utilizzi un linguaggio nativo, potresti ritrovarti con tutta la procedura che recupera il seriale e poi fregarti con un controllo stile:
Codice:
; EDX = risposta dal server -> true | false
CMP EDX, 0
JE _seriale_errato
; seriale corretto
_seriale_errato:
e ci vorrebbero 2 minuti a bypassarla, una volta individuata. ?
Inoltre dovresti valutare come generare le key, per non averne una unica (metti che qualcuno lo compra e diffonde la chiave... saresti fregato).
Ma venendo a quanto chedi...
Quindi ricapitolando ho bisogno di tre database:
- Quello per la lista dei libri che la biblioteca possiede con Titolo, Autore, Genere, Id, Ultimo prestito da collegare ad un’altra tabella (anche se non sono arrivato ancora a quel punto con SQL, quindi al momento lo inserisco come valore normale) e Numero di copie.
- Quello per i vari prestiti con Nome e cognome di chi ha preso il libro che saranno due valori distinti in una tabella con la lista dei registrati, che unirò in uno solo in questa tabella (se si può fare), Data di presa in prestito, data di restituzione, Titolo del libro sempre da collegare alla tabella della lista dei libri. Però forse è meglio mettere l’ID dell’utente e del libro al posto che nome è titolo. Quale mi consigliate?
- Quella con i vari utenti che sono registrati alla biblioteca con Nome, Cognome, Data di registrazione, Ultimo libro preso in prestito e Id
È tutto corretto o devo cambiare qualcosa nello schema?
Hai bisogno di 1 solo database, innanzitutto. Quello a cui fai riferimento tu sono tabelle. A cosa ti serve il campo "Ultimo prestito"? Puoi già ricavarlo dalla tabella dei prestiti. Ti basterebbe fare una query usando un ORDER BY ASC usando come WHERE l'id della persona e l'id del libro, e prendere il primo record, ad esempio.
No, la tabella 2 non mi sembra giusta: ricorda che il db deve essere normalizzato. Non devi ripetere i dati che ti puoi evitare (anche perchè in caso di modifica impazzisci), oltre ad occupare spazio inutilmente.
La 2 secondo me potrebbe avere questa struttura:
Codice:
// Prestiti
| ID | id_utente | id_libro | data_prestito | data_restituzione |
Questa tabella va ad associare un utente (id_utente) e un libro (id_libro) con il prestito. In questo modo non avrai ripetizioni, e risulterà anche semplice effettuare ricerche, cancellazioni etc etc.
Al tuo posto andrei ad aggiungere anche un'altra colonna, un flag, che indichi se il libro è stato
restituito. Ti agevolerà molto le ricerche.
La 3 va quasi bene, toglierei solo "ultimo libro presto in prestito", perchè tanto lo recuperi sempre in maniera analoga dalla tabella dei prestiti.
Di solito per queste operazioni si utilizzano le JOIN. Diciamo che hai il libro con ID = 1 e vuoi vedere a quante persone è stato prestato. Puoi fare una cosa come questa:
Codice:
SELECT * FROM tabella_prestiti
LEFT JOIN tabella_libri ON tabella_libri.id = id_libro
WHERE tabella_libri.id = 1 AND restituito = 0;
Qui ottieni tutti i record di tabella_prestiti che hanno come ID libro 1 e che non sono stati restituiti (restituito = 0). Puoi anche complicare la ricerca in base a quello che ti serve poi; tipo aggiungere un filtro per estrarre solo quelli in prestito a un determinato utente.
In questo modo oltre ad avere delle tabelle più ottimizzate anche le ricerche saranno più veloci (cercare su un numero è più rapido che cercare su una stringa).
Queste colonne come id_libro e id_utente saranno poi degli indici (delle chiavi esterne, ma puoi trascurare questo fatto attualmente, tutto funzionerebbe comunque).
EDIT: aggiungo una precisazione: se non vuoi la colonna 'restituito' un modo veloce per vedere se è stato restituito o no è verificare che la data di restituzione sia ad esempio NULL o diversa da NULL (a seconda che cerchi quelli restituiti o non restituiti).
