Ciao,
puoi fornirci una descrizione piu' dettagliata dei requisiti utente?
Ciao,
puoi fornirci una descrizione piu' dettagliata dei requisiti utente?
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
Questo e' probabilmente il motivo per il quale sull'altro forum ti hanno detto che e' una cosa fallimentare.
Non hai fatto un minimo di analisi e progettazione.
Per requisiti utente si intende una "lista" di requisiti che l'utente (utilizzatore) vuole ottenere dal prodotto.
Una volta ottenuto quel documento parti con la progettazione del tuo prodotto... e solo dopo varie fasi lo implementi..
Ho il sospetto che tu sia partito subito ad implementare... e i risultati saranno quelli che saranno...
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
La creazione delle entita' viene fatta leggendo i requisiti.
Se ci dici quali sono questi requisiti possiamo provare a dirti che entita' (tabelle) creare e con quali attributi...
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
Cosi ad occhio mi verrebbe da pensare di creare almeno 3 entita : Serie, Stagione, Episodio
Dove 1 Serie puo' avere N Stagione (1:N)
1 Stagione puo' avere N Episodi (1:N)
tu che tabelle avevi creato?
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
Puo' anche andare bene.
Non so che mole di dati avrai.
Comunque se volessi fare un progetto come si deve , quello che tu hai fatto e' sbagliato perche' non rispetta le regole di "Normalizzazione".
Pero' se non hai pretese strane gia' come hai fatto tu puo' funzionare
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
dal web :
QUALCHE CONSIGLIO PER EVITARE L'SQL INJECTION?
1) Controllate i dati che ricevete, quindi nel codice lato server è necessario verificare che il dato passato da una POST sia effettivamente un numero o un char.
2) Escape dei dati ricevuti dal form: una tecnica banale ma che i programmatori meno esperti non considerano. (In php, asp e altri linguaggi, esistono classi apposite per farlo come "stripslashes")
3) Non inviare le password in chiaro: ricordarsi sempre di cryptare, magari con md5, in modo che anche in condizione di fuga di dati, è quasi impossibile risalire alla password in chiaro.
4) Sostituire i caratteri speciali con entità HTML: SQL Injection solitamente permette di usare caratteri ed espressioni come 'AND user', che possono essere letti e interpretati nella query andando a compromettere l'accesso al database.
5) Effettuare periodicamente una copia backup del database.
6) Nel database, non usare nomi comuni da assegnare alla tabella amminsitratore o utente. E' comunque buona norma effettuare aggiornamenti sempre all'ultima versione del vostro database.
sicuramente solo l'escape non basta ma intanto meglio di niente
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
intanto puoi darti una letta alla normalizzazione.
Ti linko un articolo su wikipedia http://it.wikipedia.org/wiki/Normali...e_(informatica)
sicuramente in rete c'e di meglio
Non si può risolvere un problema usando lo stesso modo di pensare che ha creato quel problema.
Albert Einstein
Siate Affamati, siate Folli, siate Onesti e siate Generosi
a rigore, in tb_episodio non ci sarebbe bisogno di nome_serie, visto che ci puoi arrivare tramite tb_stagione|n_stagione. potrebbe comunque essere comodo per risparmiare una join
basta mettere le tre tabelle in join con le rispettive chiavi. dai che lo sai fare
Rispondi quotando
