[Mysql] Fondamenti di database

[lore_83]

Ciao a tutti.
Sono alle prime armi con i database in generale, quindi le domande che seguiranno potrebbero essere anche molto banali, abbiate pietà.
Sto sviluppando una semplice applicazione web con php e vorrei sciogliere qualche dubbio su Mysql (cose che non si imparano sulle guide):

1. Quanti database può/dovrebbe avere un'applicazione web?

2. E' una cosa sensata permettere agli utenti di creare (e non eliminare) le tabelle in un database. oppure l'utente dovrebbe poter solo aggiungere record?

3. Quando si devono concedere i permessi agli utenti del database (GRANT), nella voce TO cosa bisogna inserire? O meglio, da dove si prendono i dati per definire questa opzione, da una tabella da me creata che registra gli utenti?

Grazie a tutti per l'aiuto.
Ciao.

[cionci]

1. soltiamente 1
2. non tanto, a meno che l'utente in questione sia un amministratore
3. se non ricordo male il grant funziona così: TO 'utente'@'indirizzo', dove utente è il lo username usato per il login dell'utente e indirizzo c'è l'indirizzo ip o quello alfanumerico (con la possibilità di usare wildcard). Comunque è spiegato nel manuale.

Comunque solitamente è solo uno l'utente che ha accesso al database, cioè quello specificato all'interno del codice php per la connessione al server.

[lore_83]

Intanto grazie per l'aiuto.

Il mio problema principale sta proprio in questa definizione dell'utente.
Se pincopallino vuole iscriversi nel mio database (ad esempio nella tabella Users si collocano i suoi dati), lo farà utilizzando del dati di accesso (il TO di cui sopra) univoci per tutti gli utenti di un determinato livello?
E quando farà il login di nuovo vi accederà con dati univoci per tutti gli utenti (come sopra) e poi si farà il confronto del suo input (user e pass) con i record del database nella tabella Users per poter procedere?
Spero di essermi spiegato.
Grazie mille in anticipo.

[cionci]

Una cosa sono gli utenti del DB ed una cosa sono gli utenti del sito. Ci sarà un solo utente del DB che sarà specificato all'interno del codice PHP, questo sarà l'utente a cui dare il GRANT sul database.

Gli utenti del sito sono semplici record del database nella tabella Utenti all'interno del DB dedicato al sito, in base alle loro credenziali (che tu verificherai tramite il codice php al momento del login nella tabella degli utenti) darai loro permesso di fare determinate azioni, ma non direttamente sul database, sarai tu a controllare tramite codice quello che questi utenti fanno, ed in tutto questo procedimento l'utente che accede al database per fare tutte le operazioni è solo l'utente MySQL che preimpostato all'interno del codice PHP.

[lore_83]

Questa era esattamente la conferma che cercavo.
Quindi sarebbe cosa buona e giusta definire n livelli di utenti a cui concedere i permessi (amministratore e utente del sito come minimo per le mie necessità).
Grazie molte.

[cionci]

Originariamente inviato da lore_83

Questa era esattamente la conferma che cercavo.
Quindi sarebbe cosa buona e giusta definire n livelli di utenti a cui concedere i permessi (amministratore e utente del sito come minimo per le mie necessità).

Ma non i permessi sul database...dentro alla tabella Utenti andrai a specificare che tipo di utente si tratta quello record (amministratore o utente normale, 1 o 0 direi).
Se devi fare un'operazione che richiede il privilegio di amministrazione, vai a verificare se l'utente loggato ha i permessi per fare l'operazione.

[lore_83]

Perfetto, ancora più chiaro.
Sei stato preziosissimo.
Ciao.

[lore_83]

Vorrei tornare sul discorso delle tabelle create dagli utenti (di cui sopra):

Perché permettere agli utenti di creare tabelle potrebbe essere poco sensato?

Se non lo facessi mi ritroverei dei dati in una sola tabella difficili poi da estrapolare. Il nome della tabella è un modo per discriminare i risultati per una ricerca.
Sarebbe un errore agire così?

Grazie e ciao.

[cionci]

Le tabelle non si creano così all'acqua di rose. E' sbagliato e nemmeno poco
Le tabelle si creano in fase di progettazione ed a meno di stravolgimenti devono restare le stesse (poi per carità in database molto grossi magari si creano anche le tabelle, ma non sicuramente per un database di una persona che inizia).

Se io avessi 3 tabelle, una per ogni utente:

Msg1 (IDMsg, Testo)
Msg2 (IDMsg, Testo)
Msg3 (IDMsg, Testo)

ci sarebbe prima di tutto una non omogeneità degli ID (un determinato IDMsg potrebbe identificare messaggi di diversi utenti) che potrebbe addirittura a complicare tutte le query.

Questa è la soluzione ottimale:
Msg (IDMsg, IDUtente, Testo)

Ad esempio se io volessi trovare tutti gli utenti che hanno scritto un determinato messaggio, con le tabelle divise dovrei fare almeno una query per ogni tabella (4 sottoquery se si vuole recuperare l'informazione sull'utente in una sola query). Al contrario con la tabella singola basta una sola query.
Inoltre il proliferare di tabelle con l'aumentare degli utenti porta anche a problemi di prestazioni.

Poi il linguaggio SQL c'è apposta per permettere di fondere le tabelle con i join.

Come ha già giustamente detto Cionci:

in un'applicazione web di solito l'utente "principale" (nobody) che accede al DB non è altro che il server web stesso (Apache ad esempio).

In questo caso la cosa più comune è assegnare solo i privilegi SELECT, INSERT, UPDATE e DELETE al front-end del sito.

Per l'aspetto di back-end (gestionale e amministrazione DB), ci sarà immagino un Admin più vari ed eventuali utenti con permessi personalizzati.