A resposta curta:não dê aos seus usuários acesso direto ao banco de dados. Eles nunca devem ser capazes de se conectar. Somente os responsáveis pela manutenção e operações devem ter acesso ao banco de dados de produção. Isto é por razões de segurança. Em quase todos os casos em que as informações são armazenadas em um banco de dados, há um aplicativo que controla todo o acesso, lida com as atualizações reais e reforça a lógica de negócios que você escolher.
Não misture dados com lógica de negócios.
Existem alguns sistemas de banco de dados, como o Oracle, que se destacam em deixar sua loja e aplicar grande parte da sua lógica de negócios dentro do próprio banco de dados. No entanto, isso é para um tipo diferente de aplicação e uma abordagem diferente para sistemas de construção.
O MySQL não tem todas essas ferramentas para tornar isso tão fácil. Confie em mim quando digo que você está se preparando para um pesadelo de manutenção se tentar escrever a lógica de seu aplicativo em gatilhos e procedimentos armazenados e exibições, e então fornecer a seus usuários acesso direto ao banco de dados.
Quando foi a última vez que você recebeu acesso direto ao banco de dados quando se inscreveu para algo? Twitter, Netflix, Groupon, Facebook – você está interagindo com um aplicativo baseado na web que aplica as regras de negócios e lê e grava dados no banco de dados em seu nome.
Existem muitas ferramentas que facilitam a escrita de seu software de aplicativo:depuração, criação de perfil, controle de origem para código e desenvolvimento colaborativo, teste de unidade, integração contínua e ferramentas de implantação. Se você tentar escrever tudo no banco de dados, perderá tudo isso.
Aqui está um exemplo rápido de como isso funcionaria:
Estruture seu sistema de permissões em três tabelas:user, group, user_group. O usuário mantém as contas de usuário em seu sistema, o grupo mantém os vários níveis de acesso, como "admin", "cliente", "anônimo", etc. Os grupos são como você atribui níveis de acesso aos usuários.
`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;`
Agora para definir alguns grupos
`insert into `group` (name) values ('admin'), ('user'), ('anonymous');`
E um usuário, adicione-os ao grupo de administradores:
`insert into user (email) values ('[email protected]');`
`insert into user_group (user_id,group_id) values (1,1);`
Agora, esse modelo de permissões diz que um usuário pode pertencer a um ou mais grupos de segurança. Seu aplicativo verificaria esses grupos e executaria ações diferentes com base nos resultados. Vamos ver algum pseudo-código:
Carregar grupos de um usuário:
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
}
Agora em seu aplicativo, você pode ter uma função para visualizar os dados, mas produziria resultados diferentes dependendo dos grupos do usuário:
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();
}
}
Da mesma forma, suas funções para modificar dados devem verificar se os usuários têm permissões para alterar as coisas.
