Det korte svar:Giv ikke dine brugere direkte adgang til databasen. De burde aldrig kunne forbindes. Kun de personer, der er ansvarlige for vedligeholdelse og drift, bør have adgang til produktionsdatabasen. Dette er af sikkerhedsmæssige årsager. I næsten alle tilfælde, hvor information er gemt i en database, er der en applikation, som kontrollerer al adgang, den håndterer de faktiske opdateringer, og den håndhæver den forretningslogik, du vælger.
Bland ikke data med forretningslogik.
Der er nogle databasesystemer, såsom Oracle, som udmærker sig ved at udleje din butik og anvender meget af din forretningslogik i selve databasen. Dette er dog til en anden type anvendelse og en anden tilgang til byggesystemer.
MySQL har ikke alle disse værktøjer til at gøre dette så nemt. Tro mig, når jeg fortæller dig, at du sætter dig selv op til et vedligeholdelsesmareridt, hvis du prøver at skrive din applikationslogik i triggere og lagrede procedurer og visninger, og derefter give dine brugere direkte adgang til databasen.
Hvornår har du sidst fået direkte databaseadgang, da du tilmeldte dig noget? Twitter, Netflix, Groupon, Facebook -- du interagerer med en webbaseret applikation, som anvender forretningsreglerne og læser og skriver data ind i databasen på dine vegne.
Der er masser af værktøjer, der gør det nemmere at skrive din applikationssoftware:fejlfinding, profilering, kildekontrol til kode og samarbejdsudvikling, enhedstest, kontinuerlig integration og implementeringsværktøjer. Hvis du prøver at skrive alt ind i databasen, mister du alt det.
Her er et hurtigt eksempel på, hvordan dette ville fungere:
Strukturer dit tilladelsessystem som tre tabeller:bruger, gruppe, brugergruppe. Brugeren har brugerkontiene i dit system, gruppen har de forskellige adgangsniveauer såsom "admin", "klient", "anonym" osv. Grupper er, hvordan du tildeler adgangsniveauer til brugere.
`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;`
Nu for at definere nogle grupper
`insert into `group` (name) values ('admin'), ('user'), ('anonymous');`
Og en bruger, så føj dem til administratorgruppen:
`insert into user (email) values ('[email protected]');`
`insert into user_group (user_id,group_id) values (1,1);`
Nu siger denne tilladelsesmodel, at en bruger kan tilhøre en eller flere sikkerhedsgrupper. Din ansøgning vil tjekke for disse grupper og udføre forskellige handlinger baseret på resultaterne. Lad os se noget psuedo-kode:
Indlæs en brugers grupper:
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
}
Nu i din applikation har du muligvis en funktion til at se dataene, men den ville give forskellige resultater afhængigt af brugerens grupper:
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();
}
}
På samme måde bør dine funktioner til at ændre data bekræfte, at brugerne har tilladelser til at ændre ting.