Krótka odpowiedź:nie dawaj swoim użytkownikom bezpośredniego dostępu do bazy danych. Nigdy nie powinni być w stanie się połączyć. Dostęp do produkcyjnej bazy danych powinny mieć tylko osoby odpowiedzialne za utrzymanie ruchu i operacje. Dzieje się tak ze względów bezpieczeństwa. W prawie każdym przypadku, gdy informacje są przechowywane w bazie danych, istnieje aplikacja, która kontroluje cały dostęp, zajmuje się wykonywaniem rzeczywistych aktualizacji i wymusza wybraną logikę biznesową.
Nie mieszaj danych z logiką biznesową.
Istnieje kilka systemów baz danych, takich jak Oracle, które doskonale sprawdzają się w wynajmowaniu Twojego sklepu i stosują większość logiki biznesowej w samej bazie danych. Dotyczy to jednak innego typu aplikacji i innego podejścia do budowania systemów.
MySQL nie ma tych wszystkich narzędzi, aby uczynić to tak łatwym. Zaufaj mi, gdy powiem Ci, że przygotowujesz się na koszmar związany z konserwacją, jeśli spróbujesz napisać logikę aplikacji w wyzwalaczach oraz procedurach składowanych i widokach, a następnie zapewnisz swoim użytkownikom bezpośredni dostęp do bazy danych.
Kiedy ostatnio otrzymałeś bezpośredni dostęp do bazy danych podczas rejestracji? Twitter, Netflix, Groupon, Facebook – wchodzisz w interakcję z aplikacją internetową, która stosuje reguły biznesowe oraz odczytuje i zapisuje dane w bazie danych w Twoim imieniu.
Istnieje wiele narzędzi, które ułatwiają pisanie oprogramowania aplikacji:debugowanie, profilowanie, kontrola kodu źródłowego i wspólne opracowywanie, testowanie jednostkowe, narzędzia do ciągłej integracji i wdrażania. Jeśli spróbujesz zapisać wszystko w bazie danych, wszystko to stracisz.
Oto krótki przykład tego, jak to działa:
Zorganizuj swój system uprawnień w postaci trzech tabel:użytkownik, grupa, grupa_użytkownika. Użytkownik posiada konta użytkowników w Twoim systemie, grupa posiada różne poziomy dostępu, takie jak „admin”, „klient”, „anonimowy” itp. Grupy to sposób przypisywania poziomów dostępu użytkownikom.
`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;`
Teraz zdefiniuj niektóre grupy
`insert into `group` (name) values ('admin'), ('user'), ('anonymous');`
I użytkownika, a następnie dodaj go do grupy administratorów:
`insert into user (email) values ('[email protected]');`
`insert into user_group (user_id,group_id) values (1,1);`
Teraz ten model uprawnień mówi, że użytkownik może należeć do jednej lub więcej grup zabezpieczeń. Twoja aplikacja sprawdzi te grupy i wykona różne działania w oparciu o wyniki. Zobaczmy pseudokod:
Załaduj grupy użytkownika:
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
}
Teraz w swojej aplikacji możesz mieć funkcję przeglądania danych, ale dałoby to różne wyniki w zależności od grup użytkowników:
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();
}
}
Podobnie Twoje funkcje do modyfikowania danych powinny sprawdzać, czy użytkownicy mają uprawnienia do zmiany rzeczy.