La risposta breve:non dare ai tuoi utenti l'accesso diretto al database. Non dovrebbero mai essere in grado di connettersi. Solo le persone responsabili della manutenzione e delle operazioni dovrebbero avere accesso al database di produzione. Questo per motivi di sicurezza. In quasi tutti i casi in cui le informazioni sono archiviate in un database, esiste un'applicazione che controlla tutti gli accessi, gestisce gli aggiornamenti effettivi e applica la logica aziendale scelta.
Non confondere i dati con la logica aziendale.
Esistono alcuni sistemi di database, come Oracle, che eccellono nel lasciare il tuo negozio e applicare gran parte della tua logica aziendale all'interno del database stesso. Tuttavia, questo è per un diverso tipo di applicazione e un diverso approccio ai sistemi di costruzione.
MySQL non ha tutti quegli strumenti per renderlo così semplice. Fidati di me quando ti dico che ti stai preparando per un incubo di manutenzione se provi a scrivere la logica dell'applicazione in trigger, stored procedure e viste, quindi dai ai tuoi utenti l'accesso diretto al database.
Quando è stata l'ultima volta che ti è stato concesso l'accesso diretto al database quando ti sei registrato per qualcosa? Twitter, Netflix, Groupon, Facebook:stai interagendo con un'applicazione basata sul Web che applica le regole aziendali e legge e scrive i dati nel database per tuo conto.
Esistono numerosi strumenti che semplificano la scrittura del software applicativo:debugging, profilazione, controllo del codice del codice e sviluppo collaborativo, unit test, integrazione continua e strumenti di distribuzione. Se provi a scrivere tutto nel database, lo perderai tutto.
Ecco un rapido esempio di come funzionerebbe:
Struttura il tuo sistema di autorizzazioni come tre tabelle:utente, gruppo, gruppo_utente. L'utente detiene gli account utente nel tuo sistema, il gruppo detiene i vari livelli di accesso come "admin", "client", "anonimo", ecc. I gruppi sono il modo in cui assegni i livelli di accesso agli utenti.
`CREATE TABLE `user` (
`user_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`email` varchar(64) NOT NULL,
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `group` (
`group_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(32) NOT NULL,
PRIMARY KEY (`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `user_group` (
`user_id` int(10) unsigned NOT NULL,
`group_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`user_id`,`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;`
Ora per definire alcuni gruppi
`insert into `group` (name) values ('admin'), ('user'), ('anonymous');`
E un utente, quindi aggiungilo al gruppo di amministratori:
`insert into user (email) values ('[email protected]');`
`insert into user_group (user_id,group_id) values (1,1);`
Ora questo modello di autorizzazioni dice che un utente può appartenere a uno o più gruppi di sicurezza. L'applicazione verificherà la presenza di quei gruppi ed eseguirà diverse azioni in base ai risultati. Vediamo qualche pseudo-codice:
Carica i gruppi di un utente:
class User {
private $user_id;
private $groups;
private $db;
function load_groups() {
// query the database
$result = $db->query("SELECT name FROM `group` g JOIN user_group ug USING (group_id) WHERE user_id={$this->user_id}");
// save an array of group names
while ($row = $result->fetchrow()) {
$this->groups[] = $row['name'];
}
}
function is_member($group) {
if (in_array($group, $this->groups) {
return true; // user group includes this value
}
return false; // user is not in the group
}
Ora nella tua applicazione potresti avere una funzione per visualizzare i dati, ma produrrebbe risultati diversi a seconda dei gruppi di utenti:
function display_data($user_object) {
display_basic_data(); // everyone sees the basic data
if ($user_object->is_member('admin')) {
// if the user is an admin, then display bank data too
display_bank_data();
}
}
Allo stesso modo, le tue funzioni per modificare i dati dovrebbero verificare che gli utenti dispongano delle autorizzazioni per modificare le cose.