Проектирайте ER диаграма на описаната база от данни

Решение: Състезанието е едно, т.е. няма смисъл да се пази отделна таблица с негово име, дата или други характеристики. Основните обекти са етапите, съдиите, евакуаторите, екипажите и автомобилите. В задачата не е указано, но ще приемем, че един автомобил може да се кара само от един екипаж (т.е. екипажите не си сменят автомобилите в различните етапи, т.е. както е в реалните състезания), следователно те ще бъдат обединени в една таблица. Статистиката със сигурност ще бъде атрибут на свързващ обект между етапите и екипажите с техните автомобилите. Едно примерно решение е следното:

Забележка: Естествено е възможно един съдия или евакуатор да участва в повече от един етап (даже това е напълно нормално). Тоест за да бъде правилно нормализирана нашата база от данни ние би следвало да ги отделим в отделни таблици с връзки 1:M. Понеже не се очаква едно състезание да има прекалено много етапи, в настоящото примерно решение това не е направено. Ако бъде реализирано не е грешка, даже напротив.

Задача 2. Създайте базата данни чрез езика SQL.

Решение: Използваме синтаксиса на MySQL:

CREATE TABLE stages(
 number INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
 level INT(2) UNSIGNED NOT NULL DEFAULT 5,
 evacuator VARCHAR(255) NOT NULL,
 judge VARCHAR(255) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE crews(
 start_number INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
 name_pilot VARCHAR(255) NOT NULL,
 name_assistant VARCHAR(255) NOT NULL,
 blood_pilot ENUM("A+","A-","B+","B-","0+","0-","AB+","AB-"),
 blood_assistant ENUM("A+","A-","B+","B-","0+","0-","AB+","AB-"),
 branch_car VARCHAR(255) NOT NULL,
 model_car VARCHAR(255) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE stats(
 crew_start_number INT UNSIGNED,
 stage_number INT UNSIGNED,
 PRIMARY KEY(crew_start_number,stage_number),
 start TIMESTAMP NULL DEFAULT NULL,
 finish TIMESTAMP NULL DEFAULT NULL
) ENGINE=InnoDB;

ALTER TABLE stats
ADD FOREIGN KEY (crew_start_number)
    REFERENCES crews(start_number) ON DELETE CASCADE ON UPDATE CASCADE,
ADD FOREIGN KEY (stage_number)
    REFERENCES stages(number) ON DELETE CASCADE ON UPDATE CASCADE;

За решението на задачата НЕ е нужно, но за демонстрация ще вмъкнем и примерни данни:

INSERT INTO stages(number, level, evacuator, judge)
VALUES (1,3,"Ivan Ivanov","Dimitar Dimitrov"),
       (2,5,"Stoian Stoianov","Dimitar Dimitrov"),
       (3,8,"Petar Petrov","Evgeni Evgeniev"),
       (4,10,"Ivan Ivanov","Dimitar Dimitrov");

INSERT INTO crews(start_number, name_pilot, name_assistant, blood_pilot,
                  blood_assistant, branch_car, model_car)
VALUES (1,"Ventcislav Ivanov","Stefan Kozarov","A+","0-","UAZ","469"),
       (2,"Krasimir Avramov","Petar Avramov","A-","A+","Nissan","Patrol"),
       (3,"Dimitar Dechev","Asen Bratanov","AB+","AB+","Lada","Niva 1.7i"),
       (4,"Iuri Petrov","Todor Alexiev","0+","B-","UAZ","Patriot"),
       (5,"Atanas Zhelev","Ivan Stoev","A+","B-","Lada","Niva 1.6"),
       (6,"Ivan Alexandrov","Philip Trifonov","A+","AB+","Toyota","Land Cruiser");

INSERT INTO stats(crew_start_number, stage_number, start, finish)
VALUES (1,1,20110518094400,20110518101539),
       (2,1,20110518101600,20110518105619),
       (3,1,20110518105800,20110518111030),
       (4,1,20110518111100,20110518115122),
       (5,1,20110518115300,20110518121913),
       (6,1,20110518122000,20110518125910),
       (1,2,20110518133000,20110518135012),
       (2,2,20110518135200,20110518141500),
       (3,2,20110518141600,NULL),
       (4,2,20110518143500,20110518145806),
       (5,2,20110518150000,20110518153219),
       (6,2,20110518153300,20110518155113),
       (1,3,20110518160000,NULL),
       (2,3,20110518163000,20110518165555),
       (4,3,20110518165700,20110518172133),
       (5,3,20110518172200,NULL),
       (6,3,20110518173000,20110518175320),
       (1,4,20110518180000,20110518181951),
       (2,4,20110518182200,20110518184932),
       (4,4,20110518185200,NULL),
       (6,4,20110518190000,20110518193359);

Задача 3. Изведете списък с генералното класиране в състезанието. Формулата, по която се изчислява е: сумата от (сложност на етап / време на завършване).

Решение: Понеже сложността на етапите е число от 1 до 10, а разликите във времената са много голями, за да не се получават прекалено малки числа в следващата заявка съм умножил получения резултат по 10000:

SELECT crews.start_number, crews.name_pilot, crews.name_assistant,
       crews.branch_car, crews.model_car,
       SUM(stages.level*10000/(stats.finish-stats.start)) AS points
FROM crews
JOIN stats ON crews.start_number = stats.crew_start_number
JOIN stages ON stages.number = stats.stage_number
WHERE stats.finish IS NOT NULL
GROUP BY crews.start_number
ORDER BY points DESC;

Забележка: В задачите на изпита погрешно беше отбелязано, че формулата е „сложността на етапа уможена по времето на завършване“. Това естествено обръща резултите в полза на по-слабите участници (те ще събират повече точки), т.е. там класирането трябваше да бъде в обратен на показания по-горе ред (като проблемни в този вид на решение на задачата идват незавършилите състезатели – за тях би трябвало да се предвижда някакво наказание извън тази задача). Логиката на конструиране на заявката обаче си остава абсолютно същата.

Задача 4. Изведете списък с имената на пилотите, марката и моделите на автомобилите, които не са успели да завършат етап номер 3.

Решение: Тук трябва да се досетим, че за незавършил автомобил се смята не само този, който е стартирал и се е провалил (т.е. в колона „finish“ има стойност NULL), но също така и този, които въобще не е стартирал етапа (в нашите примерни данни има такава кола):

SELECT crews.name_pilot, crews.branch_car, crews.model_car
FROM crews
WHERE crews.start_number IN(
          SELECT stats.crew_start_number
          FROM stats
          WHERE stats.finish IS NULL
                AND stats.stage_number = 3
      )
      OR crews.start_number NOT IN(
          SELECT stats.crew_start_number
          FROM stats
          WHERE stats.stage_number = 3
      );

Забележка: На студентите, които не са се досетили за варианта кола въобще да не е стартирала етап 3, оценките не са им намалявани значително.

Задача 5. Изведете списък с класацията по марки автомобили, спечелили специалните етапи с категория на сложност от 7 нагоре.

Решение: Това очевидно е най-трудната задача, защото изисква специално внимание към групирането на данните за агрегатната функция и вложените заявки във FROM.

SELECT crews.branch_car, crews.model_car
FROM crews
WHERE crews.start_number IN(
          SELECT t1.crew_num
          FROM(
                SELECT stats.crew_start_number AS crew_num, stages.number AS stage_num,
                       MAX(stages.level*10000/(stats.finish-stats.start)) AS points
                FROM stats JOIN stages ON stats.stage_number = stages.number
                WHERE stages.level>=7 AND stats.finish IS NOT NULL
                GROUP BY stage_num
          ) AS t1
);

Забележка: Реално никой не се справи отлично със задача 5, но на студентите, които бяха подходили правилно им се отчете за вярна.

П.П. Генерирането на картинката и написването на горната статия на Notepad ми отне петдесет и седем минути. В последствие корекциите по кода, за да бъде изпълним на компютър (премахване на синтактични и граматически грешки), ми отнеха още дванадесет минути. Да, задачата е измислена от самия мен, но на изпита имаше още 45 минути аванс :)

CREATE TABLE users(
   id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   username VARCHAR(255) NOT NULL UNIQUE,
   password VARCHAR(255) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE orders(
   id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   count INT UNSIGNED NOT NULL,
   user_id INT UNSIGNED,
   FOREIGN KEY(user_id) REFERENCES users(id)
) ENGINE=InnoDB;

Вкарайте примерни данни разгледайте резултата от следните заявки:

SELECT orders.count
FROM orders
WHERE orders.user_id IN(
    SELECT users.id
    FROM users
    WHERE users.username = "petar"
);

SELECT orders.count
FROM orders
WHERE EXISTS(
    SELECT *
    FROM users
    WHERE users.username="petar"
      AND users.id = orders.user_id
);

Очаквано двете заявки дават един и същи изход. Разликата в изпълнението им обаче е съществена. EXISTS търси просто за наличие на ред, докато IN проверява стойностите. Реално условието (users.id = orders.user_id) присъства и в двете заявки, но във втората е зададено явно като ограничаващо условие във вложената заявка, докато в първата е свързващо условие между двете таблици.

• При използването на оператор IN първо ще се вземе стойност от външната заявка и след това ще се провери спрямо върнатите стойности от вложената. Вложената ще върне като резултат колона с уникални (distinct) и индексирани стойности. Естествено този резултат ще бъде кеширан (т.е. ще бъде преизползван в бъдеще – нещо, с което в миналото е имало проблеми) и ще бъде преизползван за следващите проверки със стойности от основната заявка;
• При използването на оператор EXISTS винаги ще се прави „full table scan“ на таблица „orders“. От това пълно нейно прелистване ще се изведат само тези редове на които условието във вложената заявка е изпълнено.

Кое от двете е по-добро? В общи линии можем да твърдим, че заявките написани с EXISTS в повечето случаи ще са по-бързи, а понякога значително по-бързи. При тях отпада нуждата от правене на „distinct“ и индексиране на резултата от вложената заявка. Практически ние директно сме указали на MySQL, че не желаем всички редове от вложената заявка, а явно указваме ограничението, т.е. един вид „помагаме на оптимизатора“.

Техниката използвана с EXISTS ще бъде много по-добър избор тогава, когато таблица „orders“ е с малко записи, а „users“ е с много и особено когато е с повтарящи се записи по колоната за сравнение. Така въпросният „full table scan“ няма да отнеме много време, а вложената заявка ще бъде много по-ефективна. Обратно – ако таблицата от вложената заявка е малка, а таблицата от главната заявка е голяма, то ефектът ще бъде в полза на оператор IN, но с малко. Така, че в общия случай заявката преработена с EXISTS ще бъде по-добрия вариант от IN. Естествено проверката на това в реална ситуация е силно препоръчителна и няма да навреди с нищо. Използвайте тази техника, която ви даде по-добри реални резултати в конкретния случай.

Много важно е да отбележим, че правилното индексиране е от основно значение за бързината на изпълнение на заявките и в двата случая. В горния пример users.id е PK и има индекс по подразбиране, но за orders.user_id е задължително да бъде създаден такъв. При изпълняване на заявки, в които аналогът на users.id не е PK е задължително да се направи индекс и по нея.

Реални проблеми при избора между IN и EXISTS идват тогава, когато в една от колоните за сравнение (или и при двете) има възможност за стойности „NULL“ и ние трябва да ги отчитаме. За повече информация прочетете раздела в документацията на MySQL.

Ще демонстрираме с един пример. Нека имаме следната база от данни:

CREATE TABLE clients(
   id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   name VARCHAR(255) NOT NULL) ENGINE=InnoDB;

CREATE TABLE products(
   id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
   name VARCHAR(255) NOT NULL) ENGINE=InnoDB;

CREATE TABLE orders(
   client_id INT UNSIGNED NOT NULL,
   product_id INT UNSIGNED NOT NULL,
   quantity INT UNSIGNED NOT NULL,
   PRIMARY KEY(client_id,product_id),
   FOREIGN KEY (client_id) REFERENCES clients(id),
   FOREIGN KEY (product_id) REFERENCES products(id)
) ENGINE=InnoDB;

INSERT INTO clients(id, name)
VALUES (NULL, "Ivan"),
       (NULL, "Petar"),
       (NULL, "Maria"),
       (NULL, "Philip");

INSERT INTO products(id, name)
VALUES (NULL, "GSM"),
       (NULL, "Bike"),
       (NULL, "Icecream");

INSERT INTO orders(client_id, product_id, quantity)
VALUES (1, 1, 2),
       (1, 3, 4),
       (2, 1, 1),
       (2, 2, 1),
       (2, 3, 2),
       (3, 2, 2),
       (4, 3, 1);

Поставяме си да решим следната задача: изведете id-тата на хората, които са поръчали продукти 1 или 2. Впечатление прави условието „или“, както също така, че връзката между clients и products е от тип M:M.

Първо ще дадем естественото решение с вложен select:

SELECT clients.name
FROM clients
WHERE clients.id IN(
      SELECT orders.client_id
      FROM orders
      WHERE product_id IN (1,2)
);

Очаквано отговорът на СУБД е:

+-------+
| name  |
+-------+
| Ivan  |
| Petar |
| Maria |
+-------+

При използването на решение с join положението не е толкова просто. Следният пример е грешен:

SELECT clients.name
FROM clients JOIN orders ON clients.id=orders.client_id
WHERE orders.product_id IN (1,2);

Ще видим, че в резултатът от него има повторения:

+-------+
| name  |
+-------+
| Ivan  |
| Petar |
| Petar |
| Maria |
+-------+

За да се избавим от повторенията ще е нужно да използваме ключова дума DISTINCT:

SELECT DISTINCT clients.name
FROM clients JOIN orders ON clients.id=orders.client_id
WHERE orders.product_id IN (1,2);

Така заявката вече ще върне правилен резултат.

Коя от двете заявки беше по-добра? Отговорът еднозначно е, че това е тази, която е с вложен select! При заявката с join първо се генерира таблицата с повторенията, а чак след това се премахнаха дублиращите се. При вложен select дублирания въобще нямаше. Ако направите по-сериозен тест с огромно количество данни с много повторения и създадени индекси по съответните колони, то ще видите, че заявката с вложен select ще се изпълни видимо по-бързо.

Когато използвате SELECT DISTINCT … WHERE… заявки (или GROUP BY), то СУБД първо ще създаде временна свързваща таблица и чак тогава ще ги агрегира. При вложен select това не се случва, съответно не се правят безсмислени операции.

Ето още един начин да направим същата заявка, но вместо IN ще използваме EXISTS:

SELECT clients.name
FROM clients
WHERE EXISTS(
      SELECT * FROM orders
      WHERE orders.product_id IN (1,2) AND orders.client_id=clients.id
);

Дали IN или EXISTS е по-добър подход ще разгледаме по-късно в отделна статия. При всички положения обаче вложения select би трябвало да дава по-добри резултати от използването на join като негова алтернатива.

Първият и най-качествен вариант за справяне с проблема е да не даваме директен достъп за въвеждане и промяна на данни в базата данни. Вместо това можем да направим набор от вградени процедури, които да правят проверка на входните параметри. За нещастие в повечето случаи писането на процедури за всяка ситуация е много трудоемка работа, а и кода става много по-трудно преносим.

Вторият доста популярен вариант е с използването на тригери (процедури, които се задействат при insert и update). По мое мнение обаче той трябва да се избягва за бази данни със сложен дизайн, защото тригерите не се активират при каскадно обновяване на данните. Може би ще разгледаме подобна функционалност когато стигнем до писане и на статия свързана с тригери.

Методът на който ще се спрем на пръв поглед е доста странен – задаване на функционалност CHECK чрез VIEW. Фундаменталната основа, на която ще стъпим е, че в MySQL върху VIEW може да се изпълняват INSERT, UPDATE и DELETE заявки. Именно това тяхно свойство ни позволява да заобиколим недостатъка от липсата на ограничение CHECK. Нека например вземем една съвсем проста таблица с продукти и техните цени:

CREATE DATABASE viewcheckexample;

USE viewcheckexample;

CREATE TABLE products(
	`id` INT AUTO_INCREMENT,
	PRIMARY KEY(id),
	`name` VARCHAR(255) NOT NULL,
	`price` DOUBLE NOT NULL,
	UNIQUE(name, price),
	CHECK(price>2)
) ENGINE=INNODB;

Както знаем условието CHECK ще бъде прието, но просто ще бъде пропуснато от MySQL, т.е. спокойно можем да вкараме продукт с price=0. Нека обаче направим изглед (VIEW), от който генерираме същата таблица, но с въведеното условие от проверката:

CREATE VIEW products_view
AS SELECT * FROM products
   WHERE price>2
   WITH CASCADED CHECK OPTION;

От тук нататък можем да проверим, че условието работи ако се обръщаме към въпросното VIEW:

INSERT INTO products_view(name, price)
VALUES ('A', 0);
ERROR 1369 (HY000): CHECK OPTION failed 'viewcheckexample.products_view'

INSERT INTO products_view(name, price)
VALUES ('A', 5);
Query OK, 1 row affected (0.00 sec)

UPDATE products_view
SET price=0
WHERE id=1;
ERROR 1369 (HY000): CHECK OPTION failed 'viewcheckexample.products_view'

UPDATE products_view
SET price=50
WHERE id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Недостатък при използвания подход е, че винаги съобщението за грешка е едно и също, т.е. потребителят няма да бъде уведомен какво точно не е в ред. И все пак въпреки, че показаната функционалност работи, ще бъде по-добре ако от MySQL просто добавят нужната функционалност колкото се може по-бързо. Остава да чакаме…

Задача: „Поправете“ всички досега разгледани примерни бази данни, като създадете необходимите VIEW при таблици с повече от един външен ключ и по този начин създадете алтернатива на CHECK условия за интегритет.

Съвсем логичен въпрос обаче идва по-късно: „а какво да правим ако искаме не първите, а вторите X реда?“. Ето ви стандартен пример – искате да направите сайт, в който да направите „страниране“ на публикациите. На първо страница ще показвате първите 10 резултата, на втора резултатите от 11 до 20, на трета от 21 до 30, и т.н. Тук определено ще срещнете затруднение в писането на заявки за извеждането на по-задните страници.

Първият подход е да се използва т.нар. OFFSET. Нека например имаме таблица с много продукти. Ако желаем да изведем на екрана всички продукти от 101 до 110, то ще напишем следната заявка:

   SELECT id, name
   FROM products
   ORDER BY id
   LIMIT 10 OFFSET 100;

OFFSET има смисъл на „отместване“. Тук все пак трябва да споменем, че колкото по-голямо отместване правим, толкова по-бавно се изпълнява заявката. Затова при доста големи бази данни тези заявки биха породили сериозен проблем откъм производителност.

Алтернативата е да се правили лимитиране в WHERE клаузата. Например ако във въпросната таблица products сме убедени, че в id на продуктите „няма дупки“, т.е. липсващи id, то можем да напишем горната заявка като:

   SELECT id, name
   FROM products
   WHERE id BETWEEN 101 AND 110
   ORDER BY id;

Тази заявка ще се изпълни доста по-бързо от предишната, но за съжаление със съответната цена. Ясно е, че при изтриване на един продукт с id в интервала [101, 110] ще се получи въпросната „дупка“ и върнатите резултати няма да са 10, а 9. Затова използването на този подход следва да се прави само ако стриктно контролираме id-тата на продуктите (в случая от примера). Това означава, че при изтриване на продукт с id X ние трябва да се погрижим да понижим с 1 id-тата на всички продукти с id по-голямо от X, или още по-добре – да променим id-то на последния въведен продукт в системата на X, като по този начин предотвратим тази „дупка“. Както се досещате това евентуално може да доведе до редица други проблеми, както и доста по-голяма загуба на производителност, особено ако често изпълняваме заявки DELETE върху таблицата.

Това обаче не решава друг основен проблем – какво гарантира, че дадения студент ще запише само и единствено предмети от този факултет? Отговорът е, че все още нищо не го гарантира! Нека демонстрираме това като построим същата диаграма в опростен вид (без таблици университети, преподаватели и задочници, а директна връзка факултети -< предмети >-< студенти):

CREATE TABLE faculties(
   `id` INT UNSIGNED AUTO_INCREMENT,
   PRIMARY KEY(id),
   `name` VARCHAR(255) NOT NULL UNIQUE
) ENGINE=INNODB;

CREATE TABLE subjects(
   `id` INT UNSIGNED AUTO_INCREMENT,
   PRIMARY KEY(id),
   `name` VARCHAR(255) NOT NULL,
   `faculty_id` INT UNSIGNED NOT NULL,
   FOREIGN KEY(faculty_id) REFERENCES faculties(id),
   UNIQUE(name, faculty_id)
) ENGINE=INNODB;

CREATE TABLE students(
   `id` INT UNSIGNED AUTO_INCREMENT,
   PRIMARY KEY(id),
   `name` VARCHAR(255) NOT NULL,
   `faculty_id` INT UNSIGNED NOT NULL,
   FOREIGN KEY(faculty_id) REFERENCES faculties(id),
   UNIQUE(name, faculty_id)
) ENGINE=INNODB;

CREATE TABLE subjects_students(
   `student_id` INT UNSIGNED NOT NULL,
   `subject_id` INT UNSIGNED NOT NULL,
   PRIMARY KEY(student_id, subject_id),
   FOREIGN KEY(student_id) REFERENCES students(id),
   FOREIGN KEY(subject_id) REFERENCES subjects(id)
) ENGINE=INNODB;

Сега да вмъкнем информация в таблиците и да демонстрираме проблема:

INSERT INTO faculties(`name`)
      VALUES ("FKSU"),("FET");

INSERT INTO subjects(`name`, `faculty_id`)
VALUES ("Bazi Danni", (SELECT id FROM faculties WHERE name="FKSU")),
       ("Sapromat", (SELECT id FROM faculties WHERE name="FET"));

INSERT INTO students(`name`, `faculty_id`)
VALUES ("Ivan Ivanov", (SELECT id FROM faculties WHERE name="FKSU"));

Така имаме два факултета (FKSU и FET), които имат по един учебен предмет всеки:

SELECT * FROM faculties;
+----+------+
| id | name |
+----+------+
|  2 | FET  |
|  1 | fksu |
+----+------+

SELECT * FROM subjects;
+----+------------+------------+
| id | name       | faculty_id |
+----+------------+------------+
|  1 | Bazi Danni |          1 |
|  2 | Sapromat   |          2 |
+----+------------+------------+

mysql> SELECT * FROM students;
+----+-------------+------------+
| id | name        | faculty_id |
+----+-------------+------------+
|  1 | Ivan Ivanov |          1 |
+----+-------------+------------+

Ние сме сигурни, но нека все пак се убедим, че проблема е налице – ще запишем Иван Иванов едновременно и за двата предмета, които са от различни факултети:

INSERT INTO subjects_students(subject_id, student_id)
VALUES ((SELECT id FROM subjects WHERE name="Bazi Danni"),
              (SELECT id FROM students WHERE name="Ivan Ivanov")),
       ((SELECT id FROM subjects WHERE name="Sapromat"),
              (SELECT id FROM students WHERE name="Ivan Ivanov"));

Проблемът вече е налице и имаме невалидна информация в базата от данни:

SELECT students.name AS student, faculties.name AS faculty
FROM students JOIN faculties ON students.faculty_id = faculties.id
WHERE students.name="Ivan Ivanov";
+-------------+---------+
| student     | faculty |
+-------------+---------+
| Ivan Ivanov | FKSU    |
+-------------+---------+

SELECT students.name AS student, faculties.name AS faculty
FROM students
JOIN subjects_students ON students.id = subjects_students.student_id
JOIN subjects ON subjects.id = subjects_students.subject_id
JOIN faculties ON faculties.id = subjects.faculty_id
WHERE students.name = "Ivan Ivanov";
+-------------+---------+
| student     | faculty |
+-------------+---------+
| Ivan Ivanov | FKSU    |
| Ivan Ivanov | FET     |
+-------------+---------+

Очевидно, за да се справим с този проблем ние трябва да НЕ позволяваме в таблицата subjects_students да се записват предмети, които са от „чужд“ факултет. Това може да се постигне чрез ограничение CHECK. Ето как можем да поправим предишната CREATE TABLE заявка, за таблица „subjects_students“:

CREATE TABLE subjects_students(
   `student_id` INT UNSIGNED NOT NULL,
   `subject_id` INT UNSIGNED NOT NULL,
   PRIMARY KEY(student_id, subject_id),
   FOREIGN KEY(student_id) REFERENCES students(id),
   FOREIGN KEY(subject_id) REFERENCES subjects(id),
 CHECK (subject_id = (SELECT subjects.id FROM subjects WHERE subjects.faculty_id=( SELECT students.faculty_id FROM students WHERE students.id = student_id )) )
) ENGINE=INNODB;

Така ние въвеждаме ограничение, чрез което забраняваме добавянето на предмет от различен факултет от този на студента. За съжаление тази функционалност все още не работи в СУБД MySQL. До сега (най-новата версия е MySQL 5.1.41) CHECK ограниченията се приемат от MySQL като валидни записи, но в последствие не се проверяват при изпълнение на заявки INSERT (тоест вие можете да продължите да въвеждате невалидни данни). Очаква се подобна функционалност да бъде въведена скоро, но за сега не е налична. Все пак е добре да я познавате, защото в други СУБД като Oracle например функционалността CHECK работи отлично. За момента, при използване на MySQL, е в ръцете на програмиста да се проверяват тези циклични зависимости през софтуера достъпващ базата от данни.

Затова при използване на MySQL засега бъдете внимателни – интегритета на данните може да бъде нарушен дори когато ограниченията са уж написани перфектно – различните СУБД имплементират функционалности по различен начин (а както виждате понякога въобще не се имплементират). Ако все пак желаете да реализирате споменатата по-горе функционалност и контрола все пак да бъде на ниво база от данни с MySQL, а не при приложението – тогава забранете заявки INSERT и въведете алтернатива чрез съхранени процедури.

Задача: Начертайте опростената ER диаграма на примерната база от данни

Задача: „Поправете“ цикличната зависимост в базата от данни banks, която беше разгледана в предишни статии, чрез въвеждане на ограничение/я CHECK.

Задача: Създайте съхранена процедура за „записване на студент към предмет“, при която не се позволява записването към предмет от „чужд“ факултет.

CREATE TABLE university(
   `id` INT UNSIGNED AUTO_INCREMENT,
   `name` VARCHAR(255) NOT NULL UNIQUE,
   PRIMARY KEY(id)
)ENGINE=INNODB;

Казахме, че PRIMARY KEY винаги е едновременно NOT NULL и UNIQUE по подразбиране, както и че е възможно да направим комбинация от две или дори повече колони заедно PRIMARY KEY.

В така зададените възможности не можем обаче да се справим с друг проблем – какво ще стане ако искаме да направим комбинация от две или повече колони уникални, но в същия момент НЕ желаем да ги правим PRIMARY KEY? Ето един пример – в горната таблица вместо име на университет ще пазим име и град:

CREATE TABLE university(
   `id` INT UNSIGNED AUTO_INCREMENT,
   `name` VARCHAR(255) NOT NULL,
   `city` VARCHAR(255) NOT NULL,
   PRIMARY KEY(id)
)ENGINE=INNODB;

Така ние можем да въведем „Технически Университет“ от град „София“, но и „Технически Университет“ от град „Варна“. Така името не може да бъде UNIQUE, но и града не може да бъде UNIQUE (имаме и „Софийски Университет“ от „София“). Всичко щеше да бъде наред ако не се явяваше проблемът, че никой всъщност не ни спира да въведем „Технически Университет“ от град „София“ два или повече пъти. Те ще се различават само по своя id, което обаче си е променлива за вътрешно ползване. Така ние определено се сблъскваме с проблема „дублиране на информация“. В най-честия случай ние НЕ желаем това.

Подсказаното решение е да направим комбинацията от тези колони уникална. Това се постига когато „изнесем“ UNIQUE KEY CONSTRAINT по абсолютно същия начин както го правихме досега с PRIMARY KEY:

CREATE TABLE university(
   `id` INT UNSIGNED AUTO_INCREMENT,
   `name` VARCHAR(255) NOT NULL,
   `city` VARCHAR(255) NOT NULL,
   UNIQUE KEY (name, city),
   PRIMARY KEY(id)
)ENGINE=INNODB;

Всъщност спокойно можете да пропуснете думата „KEY“ и да използвате само „UNIQUE“. MySQL ще разбере това съкращение коректно.

Задача: Проверете в преди показаните примери от базата данни с университет и базата данни с банки дали този проблем с дублиране на записи е наличен в различните таблици и ако да – поправете ги!

тема:

До къде може да стигнем с номализацията?

Никола Костадинов Симеонов, ТУ-София, ФКСУ, гр. 57

Нормализацията е един от основновните процеси при проектиране на бази данни. Най общо казано нормализацията премахва повтаряемостта и минимизира излишъка от данни. Резултатът е по добра организация,по добра използваемост на паммета и премахване на аномалиите в базата данни. Нормализацията не винаги е най-доброто решение за дадена база данни, например при data Warehouse бази данни се прилага съвсем различен подход(използват се силно денормализирани бази данни). Или иначе казано сляпото прилагане на всички нормални форми може да доведе до катастрофални последици-изключително голям брой таблици,сложни заявки за сливане и най-важното много лоша производителност. Това в крайна сметка може да направи базата данни неизползваема. Така стигаме до въпроса как да намерим баланса?Да избегнем аномалиите и да и във същото време да запазим високата производителност и време за отговор на базата данни.

В този реферат ще се опитам да дам отгоровор на тези въпроси, също така ще разгледам какво точно се прави след 3-та нормална форма ,защо се прави и в кои случаи не е препоръчително да се прави. Най-накрая ще се опитам да обобщя личната ми позиция по тази много важна тема защото тя има важно място в цялостния процес на разробтка на софтуер. Отделянето на достатъчно време за доброто проектиране на базата данни още от началото ще спести много проблеми и усилия по нататък.

Първо нека накратко разгледаме нормалите форми и как се прилагат.

1НФ: Една таблица е в първа нормална форма, тогава и само тогава, когато не съдържа повтарящи се атрибути или групи от атрибути.

2НФ: Таблицата трябва да е в 1НФ и всички неключови стойности трябва да са напълно функционално зависими от първичния ключ. Не са позволени частични зависимости.

3НФ: Премахват се непреките зависимости. Това са полетата които са непряко зависими от първични ключ. Например поле е фунцкционално зависимо на друго поле, а то от своя страна е зависимо от първичния ключ.

Boyce-codd Normal Form (BCNF): Всяка детерминанта трябва да бъде кандидат ключ. Детерминант е произволно поле от което са напълно функционално зависими други полета. Ако съществува един единствен кандидат ключ 3НФ и BCNF са едно и също.

4НФ: Трябва да се премахнат многостойностните зависимости.

5НФ: Трябва да се премахнат цикличните зависимости

Domain key Normal Form (DKNF): Тази форма е по скоро определение на това как трябва да излегжда нормализирана до съвършенство база данни.

• Не трябва да съществуват аномалии при записване, обновяване или триене на данни. Иначе казано всеки запис трябва да бъде директно достъпен по всякакъв начин така че да не възникват грешки;
• Всеки запис във всяка таблица трябва да бъде уникално идентифициран и свързан с първичния ключ в своята таблица. Това означава че всяко поле трябва да е пряко определено от пърчвичния ключ;
• Всички проверки за типа на данните се извършват в самата база данни(Като се има предвид производителноста това е крайно нежелателно в комерсиална работна среда. По-добър подход би бил  да се раздели функционалността между базата данни и приложението).

Несъмнено прилагането на първите две форми, като създаване на разширяващи(master-detail връзки) в 1НФ и Отделяне на статичните данни в 2НФ е необходимо. Не само че помага за избягване на аномалите те са необходими за да съществува релационния модел. Прилагането на 3НФ също е доста срещано но с всяка следваща форма модела на базата става все по раздробен и броя на таблиците нараства. От там нарастват и SQL заявките за сливане и намалява производителноста.

Защо да отиваме след 3-та нормална форма?

Прилагането на първите 3 нормални форми може да се каже че елиминира 90% от аномалиите при изтриване , обновяване или въвеждане. Използването на останалите 3 се нормални форми се прилагат в някои по специфични случаи за да се „доизглади” модела.

Тук искам да дам няколко нагледни примера как се прилагат формите след 3-та и да покажа защо по мое мнение в много случаи това е излишно и е признак на следване на математическо съвършенство а не проектиране на работна база данни.

Премахване на едно към едно NULL полета

Това е често срещан подход за нормализация след 3-та НФ при който се премахват потенциално нулевите полета. Тук съм дал следния пример съществува база данни за библиотека като една от таблиците и се казва EDITION. Полетата rank и ingram_units са потенциално с нулеви стойности. Може да нормализираме модела като отделим тези полета в отделна таблица и по този начин спестим място. Създаваме новата таблица RANK с първичен ключ ISBN номера и двете потенциално нулеви полета. Връзката която се получава в този случай между RANK и EDITION таблиците е нула или едно към едно. Това означава че ако съществува RANK задължително трябва да съществува EDITION запис, обаче обратното не е задължително може да съществува издание което не е оценено и не е получило RANK.

В случая с таблицата RANK при от фиг 1.1 полетата rank и ingram_units не са зависими едно от друго и са напълно независими. Много е възможно едното от полетата да бъде нула а другото не. Ако продължим с нормализацията до крайности може да разделим таблицата на две нови както е показано на фиг 1.2. Това ниво на нормализация е доста абсурдно и отчасти безмислено. В днешно време паметта е евтина а процесорното време скъпо така че се обезсмиля разделянето на таблицата RANK.

Boyce-Codd Normal Form (BCNF)

Нека сега разгледаме прилагането на тази форма. При нея базата данни трябва да е вече в 3-та НФ и всяка таблица да има само по един кандидат-ключ. Кандидат ключ е поле което е възможно да се използва за първичен ключ.

От лявата страна на Фиг.2 е дадена таблица която съдържа естествени (основни) ключови полета като customer_name и address и изкуствен(допълнителн) customer_id. Допълнителния ключ customer_id е добавен защото е по ефиктивен при търсене и по лесно се обработва като цяло. От дясната страна на Фиг.2 е показана таблицата Customer разбита на отделни таблици според точното прилагане на Boyce-Codd Normal Form. Както се вижда раздробяването на таблицата customer на толкова много таблици е меко казано нецелесъобразно!

4-та Нормална Форма

При нея таблицата трябва да е в 3-та нормална форма или 3-та нормална форма с BCNF. При прилагането на 4-та нормална форма трябва да се премахнат многостойностните зависимости. Това означава че единични стойности а не съставни трябва да са зависими от първичния ключ.

Многостойностно поле е такова поле което съдържа колекция масив от стойности от някакъв тип разделени със запетаи.
Фигура 3 показва таблицата Employee с различните умения които притежават служителите и техните сертификати. Трябва да се отбележи че уменията и сертификатите не само че не са зависими едно от друго но са добавени в списък разделен със запетаи.

За да приложим 4-та нормална форма премахваме многостойностните зависимости като разделяме таблицата Employee на три таблици Employee_Skill, Employee и Employee_Certification:

Във същността си 4-та нормална форма пренася колекцията от многостойностните елементи във различни таблици и записи и така прави всеки запис по лесен за директен достъп.

5-та Нормална Форма

За да приложим 5-та нормална форма таб таблиците трябва да са вече в 4-та. При 5-та нормална форма се премахват цикличните зависимости. Циклична зависимост се получава когато едно поле зависи от друго поле а то от своя страна зависи директно или индиректно от първото поле. 5-та нормално форма се нарича още „Проекционна нормална форма”. Думата проекционна идва от това че метода създава нови таблици съдържащи подмножества от данните на оригиналната таблица. Циклична зависимост се получава когато например в съставен първичен ключ с три полета всяко от полетата е зависимо от всички други освен от себе си. В конкретния пример името на проекта е зависимо от неговия мениджър и от служителите които работят по него,същото се отнася и за останалите две полета името на служителя е зависимо от мениджъра и от проекта по който работи,за третото поле се отнася същото името на мениджъра е зависимо от проекта който ръководи и от сложителите които управлявава. Таблицата от фигура 5 с съставния ключ може да се раздели на 3 таблици кадето полета са разделени по двойки и така вече не съществува циклична зависимост в отделните таблици.

И така това са нормалните форми. В повечето случаи прилагането на формите води до определени подобрения в структурата и до избягване на аномалии но както вече няколко пъти споменах важно е да се има предвид фактора производителност и то още от самото начало на проектирането на базите данни.

Нужно да се нормализира модела след 3-та нормална форма?

В някои случаи може и да е но в голямата си част работните комерсиални бази данни не стигат дотам. Моето лично мнение е, че проектантите на бази данни не трябва да се страхуват да не използват висококо ниво на нормализация а по скоро обратното. От първостепенна важност е проектанта да може да „види” модела на базата през погледа на софтуерния разработчик и крайния потребител и точно да се определят изискванията.

За да определите нивото на нормализация е добре да си зададете следните въпроси:

1. Какъв тип е базата данни? Дали е OLTP, OLAP или warehouse?

2. Какви са по същество заявките към базата? Дали са повече за добавяне или са за извеждане?

При бази данни при които заявките са добавяне са повече от заявките за извеждане на информация е в общия случай е по добре да се използва по дълбоко ниво на нормализация и обратното ако заявките за извеждане са повече от тези да добавяне тогава може да си позволим по слаба нормализация.

Фактори които влиаят на нивото на нормализация:

Тук съм подбрал основните фактори които трябва да вземем предвид при прилагането на нормализацията.

1. Коефицентът на добавени/изведени стойности.

2. За какво се използва базата за тразнакционно записване/обработване или е система за подпомагане на избора.

3. Какво е времето за отговор от което се нуждаем при добавяне изтриване и обновяване.

4. Колко е като обем пика на зареждане на данни в базата данни за определен период от време.

5. Дали базата данни е съставена като централизирана система или е разпростряна на няколко места.

6. Как ще контролираме транзакционните процеси дали ще използваме еднофазно или многофазно потрвърждаване.

7. Дали ще се използва временно кеш съхранение на даден тип данни.
След отговора на тези въпроси ще имаме обща представа каква ще точно нашата система и много по лесно ще определим нивото на нормализация.

Каде трябва да теглим чертата?

В случая няма еднозначен отговор но в 90% от случаите това е 3НФ или 3НФ с BCNF. Един добър подход би бил да се остави до някаква степен приложението да проверява данните които се въвеждат и извежда с цел в крайна сметка да се покрият изискванията за скорост и производителност. В случаите когато ситуацията налага да се използват по дълбоки нива на нормализация тогава могат да се използват и 4-та и 5-та нормална форма само, че тогава проблема със нормализацията става много по-сложен и в повечето случаи не си заслужава да се стига до там.

Използвана литетература :

1. Beginning Database Design – Gavin Powel (Wrox, 2006),
2. Database Design Know It All – Stephen Buxton, Thomas P. Nadeau (Morgan Kaufmann Publishers,2009).
3. Beginning.Database.Design.From.Novice.to.Professional –Clare Churcher (Apress, 2007).

Тема:

„Постигане на висока производителсност
на базата данни чрез разделяне на части“

Павлина Евгениева Темелакиева, ТУ – София , ФКСУ, гр. 63А

Преди няколко години са писани много статтии за „Откритие за отлична производителност” (http://www.tdan.com/i016fe03.htm), където се говори срещу разбирането, че кодът на SQL е основният отговорник за производителността в  база от данни. Вместо това, беше изтъкнат факта, че добрият физически дизайн  е сред водещите компоненти за голямо бързодействие на базата от данни. В допълнение е добавено проучване на Oracle, което илюстрира как лошият дизайн е основният виновник за забавянето на базата. В годините след това все още се застава зад мнението, че вески администратор на бази данни, който иска високо бързодействие на базата си трябва да инвестира в добре обмислен и лесен за разбиране физически дизайн, за да може да направи крайния потребител доволен, а не търпеливо изчакващ изпълнението на заявката си( което търпение в много случаи се превръща в изнервяне).
В новите версии на MySQL( от 5.1)  има потенциално оръжие за високо бързодействие на много натоварени обемни бази от данни, наречено средство за разделяне.

Какво е разделяне на части?
Това е техника при физическия дизайн на базата от данни, с която много администратори са добре запознати. Въпреки че разделянето може да бъде използвано за реализацията на много обекти като основната цел е да се намали количеството на четенето на данни за някои операции в SQL, така че цялото време за отговор да бъде намалено.

Има две основни форми на разделяне на части:

Хоризонтално Разделяне – тази форма е разделяне на сегменти на редовете в таблицата. Така да се формират различни групи от физически разположени в редове данни, към които може да се обърнем иднивидуално( една част) или колективно( една към всички части). Всички колони, определени за някоя таблица могат да бъдат намерени във всяка поредица от части и така нито един атрибут на таблицата няма да се изгуби. Пример за хоризонтално разделяне може да бъде таблица, която съдържа 10-годишна история с данни за фактуи , които биват разделени на 10 различни части, всяка от която съдържа  количество данни за една година.

Вертикално Разделяне – тази схема за разделяне обикновено е използвана, за да намали широчината на  целевата таблица като някоя таблица се съедини верикално като по този начин само по-съществени колони от данни ще останат, като всяка част ще съдържа всички колони. Пример за вертикално разделяне може да бъде таблица, чиито колони съдържат голямо количество тескт или са от тип BLOB и не са адресирани често. Те биват разбити на две таблици, които съответно съдържат колоните с най-честа адресация в едната и рядко адресиран текст или BLOB данни в другата.

Преди производителите на бази данни да започнат да създават този метод ( най-вече хоризонтален), администраторите на бази данни и модераторите трябваше ръчно да създават отделни структури от таблици, за да съхраняват желаните части, които или съхраняват излишък от данни или са свързани заедно, за да сформират един логически родителски обект. Тази практика  е остаряла за по-голямата част от хоризонатлното разделяне, въпреки че все още е подходящо за вертикално разделяне.

Разделяне в MySQL
Едно от нововъведенията в MYSQL е поддръжката на хоризонтално разделяне. Добрите новини за MYSQL и новото попълнение са, че всички основни форми на разделяне се поддържат.

Обхват: това състояние позволява на администраторите да определят специфичен обхват, в който данните са записани. Например даден администратор може да създаде разделена на части таблица, която е сегментирана на три отделни части, които съдържат данни за 1980-та, 1990-та и всичко след 2000 година.
Хеш: това състояние позволява на администраторите да разделят данните, базирани на изчислен хеш ключ, който е определен от една или повече колони в таблицата като крайната цел е равновесно разпределение на данните в частите. Например, даден администратор може да създаде разделена таблица, която има 10 части, базирани на първичния ключ на таблицата.
Ключ: специална форма на Хеша, където MySQL гарантира разпределение на данните през системно- генериран хеш ключ.
Лист: този метод позволява да се сегментират данни, базирани на предефиниран лист от стойности, който самият администратор определя. Например даден администратор може да създаде разделена таблица, която създаде 3 части, формирани от данните за години 2004, 2005, 2006.
Комбиниран(composite): това финално състояние за разделяне позволява на даден администратор да изпълнява подразделяне, когато таблицата първоначално е разделяна. Например обхватното разделяне,след което всяка част бива сегментирана равномерно от друг метод(например хеш).
Паралелно изпълнение на заявки с релционни оператори: освен разделянето на таблици има други – физически – методи за разделяне. В следните параграфи ще бъдат разгледани някои от тях.

Всъщност разделянето на данни е първата стъпка в разделянето на части на релационните графи. Основната идея е да се използват паралелни потоци от данни, вместо да се пишат отделни оператори за това. Този подход позволява използването на непроменяни, съществуващи практики, чрез които да се приложат релационните оператори паралелно. Всеки релационен оператор има серия от входни портове, на които всеки ред от таблицата „пристига” и изходящ порт, от който излиза целият поток от данни, пратени от даден оператор. Паралелното поддържане на поток от данни се реализира чрез разделяне и съединяване на потоци от данни в тези последователности от портове. Този метод позволява използването на съществуваща последователност от оператори, за да се поддържа паралелно управление.

Разглеждаме обхождане на релация А, която е разделена в рамките на три диска във фрагменти съответно A0, A1 и A2. Това обхождане може да бъде осъществено като обхождане на три оператора за сканиране, които изпращат отговрите си до общ оператор за изход. Изпълнителят на паралелната заявка създава троен сканиращ процес(фиг. 1) и и ги насочва да почерпят ресурс от три различни входни потока(A0, A1, A2). Той също ги насочва към общ възел. Всеки скан може да работи на отделен процесор или диск. И така първият основен паралелен оператор е merge, който може да комбинира няколко даннови потока в единствен последователен поток. Операторът за присъединяване (merge) се грижи да насочи данните в една точка.

Ако многоетаптна паралелна операция трябва да се изпълнява паралелно, то данните отново трябва да бъдат насочени(разделени) на няколко независими потока. Т.нар split-operator се използва, за да раздели или да клонира поток от редове в таблицата, произведени от релационните оператори. Операторът за разделяне превръща една или повече величини от резултантните редове в таблиците в поредица от процеси(фиг. 2).

Като пример, засягащ двата разделящи оператора е показана следната SQL заявка  и фигура 3:

Да предположим, че трите процеса са използвани, за да изпълнят join оператора, а 5 други процеса изпълняват двата сканиращи оператора – три сакниращи части за релация А, докато други 2 части се сканират в релаация В. Всяка от трите сканиращи части от релация А ще има същия обединяващ оператор, изпращащ всички редове в интервала „A-H” към порт 1 на join процес 0, всички „I-Q” към порт 1 на join процес 1 и всички „R-Z” към порт 1 на  join процес 2.

Подобно на това двата B сканиращи възли имат същия обединяващ оператор с изклчючение на това, че техните изходи са обединени от порт 1, а не от 0 за всеки join процес. Всеки join  процес вижда всяка поредица от входни потоци А(левите сканиращи възли) от порт 0 и съответно поредица от входни потоци Б(десните сканиращи възли) от порт 1. Изходите на всеки join са поред разделени на три потока, базирани на  някакъв разделителен критерий на релацията C.  За да се изясни този пример, разглеждаме първия join процес във фигура 3(процесор 5, портове 0 и 1, процес 3). Той ще получи всички релации А и редовете в интервала  „А-Н”, обединени в един поток на порт 0 и всички редове „А-Н” обединени в един поток от порт 1. Ще ги присъедини, използвайки хеш-join, sort-merge join или друг.

Ако всеки от тези процеси са на независим процесор с независимо записващо устройство, ще има малки смущения измежду тях. Операторът за разделяне тук е само даден като пример. Други оператори за разделяне биха могли да дублират входен поток информация или да го раздели чрез хеш.

Операторите за просъединяване и разделяне имат значителен контрол и буферна конструкция. Това предотвратява някой оператор да стигне твърде далеч при изчисляването. Когато буферът на оператора за разделяне се препълни, той забавя релационния оператор докато се освободи място на изхода за данните.

Има много ползи от разделянето на части, но двете основни предимства са:

Растяща производителност: по време на претърсващите операции – оптимизаторът на MySQL знае коя част съдържа данните, които ще задоволят някоя специфична заявка и ще има достъп само до оне необходими части по време на изпълнението на самата заявка. Например една таблица с един милион редове може да бъде разбита на 10 различни части с обхватния метод, така че всяка част да съдържа 100,000 реда. Ако заявката разбере, че ? трябват данни от само една от частите и все пак е необходимо преглеждане на цялата таблица, то ще бъдат сканирани само 100,000 реда вместо 1 милион. Очевидно трябва да бъде по-лесно за MySQL да обходи 100,000 реда вместо 1 милион, следователно заявката ще се изпълни много по-скоро. Същата полза произлиза от необходимостта да бъдат индексирани и отделните шасти, на които бива разделена таблицата, т.е. създават се локални индекси за отделните таблици. В крайна сметка става възможно маркирането на разделените таблици  през различни физически пътища, специфизирайки  директорията на отделните части. Това позволява физическото I/O  съравнование да бъде намалено, когато множество части бъдат достигнати по едно и също време.

Опростено  ръководене на данните – разделянето позволява на администраторите да имат повече контрол над това как данните са управлявани във вътрешността на базата. Създавайки части, администраторъ опростява начинът на изпълнение на някои операции с данните. Например, той може да изтрие специфични части в една таблица, докато останалите части остават недокоснати. По-натам, частите се поддържат автоматично от MySQL, така че администраторът не трябва ръчно да разделя и поддържа хоризонтално разделяне на части за някоя таблица. Например администраторът на базата може да създаде таблица с история, която съхранява данни за клиенти, които са разделени според някакъв годишен критерий. Тези части са автоматично приложени и разделени от сървъра на базите данни с никаква намеса да администратора.

Разделянето на части в действие:
От гледна точка на дизайна за подобряване на бързодействието на базата основно сме заинтересовани . Използвайки подходящо разделянето на части, драматично може да се подобри работата на базата. Следният пример ще илюстрира това:
За да видим ползата от разделянето на части, ще създадем идентична MyISAM таблици, които съдържат информация, свързана с дати, но нека да отделим една, а другата да оставим като стандартна хийп таблица. За нашата отделена таблица ще направим разделяне, базирано на полето година:

CREATE TABLE part_tab (
	c1 int default NULL ,
	c2 varchar(30) default NULL ,
	c3 date default NULL ,
) engine=myisam
PARTITION BY RANGE (year(c3)) (
	PARTITION p0 VALUES LESS THAN (1995),
	PARTITION p1 VALUES LESS THAN (1996) ,
	PARTITION p2 VALUES LESS THAN (1997) ,
	PARTITION p3 VALUES LESS THAN (1998) ,
	PARTITION p4 VALUES LESS THAN (1999) ,
	PARTITION p5 VALUES LESS THAN (2000) ,
	PARTITION p6 VALUES LESS THAN (2001) ,
	PARTITION p7 VALUES LESS THAN (2002) ,
	PARTITION p8 VALUES LESS THAN (2003) ,
	PARTITION p9 VALUES LESS THAN (2004) ,
	PARTITION p10 VALUES LESS THAN (2010),
	PARTITION p11 VALUES LESS THAN MAXVALUE
);

Трябва да се забележи това, че създадохме части за специфична година и завършихме с една, побираща в себе си всички част, която да събере всички данни, които не попдат в никоя друга част. Сега нека създадем таблица с огледален образ в MyISAM, която да не е разделена:

create table no_part_tab(
	c1 int(11) default NULL,
	c2 varchar(30) default NULL,
	c3 date default NULL
) engine=myisam;

Сега нека създадем процедура, която ще запълни нашата разделена таблица с 8 милиона реда, които разпределят данните по равно между двете части. Веднъж запълнена, ще сложим същите данни в нашата клонирана, неразделена на части MyISAM таблица:

DELIMITER //

CREATE PROCEDURE load_part_tab()
BEGIN
	DECLARE v INT DEFAULT 0;
	WHILE v < 8000000
	DO
		INSERT INTO part_tab
		VALUES (v,'testing partitions',
				adddate('1995-01-01',
				(rand(v)*36520) mod 3652));
		SET v = v + 1;
	END WHILE;
END
//
Query OK, 0 rows affected (0.00 sec)

DELIMITER ;

CALL load_part_tab();
Query OK, 1 row affected (8 min 17.75 sec)

INSERT INTO no_part_tab
SELECT * FROM part_tab;
Query OK, 8000000 rows affected (51.59 sec)
Records: 8000000  Duplicates: 0  Warnings: 0

С вече готовите таблици нека да видим какъв ще бъде резултатът от двете таблици, последвани от пояснения – неразделяната на части първо и след това тази, която разделихме:

SELECT count(*)
FROM no_part_tab
WHERE c3 > date '1995-01-01' and c3 < date '1995-12-31';
+----------+
| count(*) |
+----------+
|   795181 |
+----------+
1 row in set (38.30 sec)

SELECT count(*)
FROM part_tab
WHERE c3 > date '1995-01-01' and c3 < date '1995-12-31';
+----------+
| count(*) |
+----------+
|   795181 |
+----------+
1 row in set (3.88 sec)

Лесно се заблеязва, че достъпът до разделената таблица доставя до 90% по-бърз отговор в сравнение с неразделената.

В заключение можем да изтъкнем още някои предимства на разделянето на части:

• Всички акумулатори за съхранение поддържат разделяне(MyISAM, InnoDB, Archive и т.н.);
• Поддържането на индекси за разделени таблици включва локални индекси, които копират всяка част в схема 1:1. С други думи, ако разделената таблица има 10 части, то локалните индекси за тази таблица също ще съдържат 10 части;
• Всички SHOW команди поддържат отговор от разделени таблици и индекс метадата;

Използвани източници:

http://dev.mysql.com/tech-resources/articles/performance-partitioning.html
http://msdn.microsoft.com/en-us/library/aa177979(SQL.80).aspx
http://www.tdan.com/i016fe03.htm

Нека припомним как работеха LEFT и RIGHT JOIN. За целта ще направим многотаблична заявка по колоната „цена“:

SELECT * FROM vegetables
LEFT JOIN fruits ON vegetables.price = fruits.price;
+----+------------+-------+------+--------+-------+
| id | name       | price | id   | name   | price |
+----+------------+-------+------+--------+-------+
|  1 | krastavici |     4 | NULL | NULL   |  NULL |
|  2 | domati     |     5 | NULL | NULL   |  NULL |
|  3 | kartofi    |     3 |    1 | banani |     3 |
+----+------------+-------+------+--------+-------+
3 rows in set (0.00 sec)

Резултата е точно това, което очаквахме – само banani имат една и съща цена с kartofi и затова от втората таблица само един ред не е с резултат NULL. В RIGHT JOIN се случваше същото, но в обратна посока:

SELECT * FROM vegetables
RIGHT JOIN fruits ON vegetables.price = fruits.price;
+------+---------+-------+----+----------+-------+
| id   | name    | price | id | name     | price |
+------+---------+-------+----+----------+-------+
|    3 | kartofi |     3 |  1 | banani   |     3 |
| NULL | NULL    |  NULL |  2 | iagodi   |   2.5 |
| NULL | NULL    |  NULL |  3 | chereshi |     7 |
+------+---------+-------+----+----------+-------+
3 rows in set (0.00 sec)

Е, вече може би се досетихте как можем да постигнем FULL JOIN – просто трябва да обединим резултата от двете заявки и да премахнем дублиращите се редове (т.е. да използваме UNION без ALL):

(SELECT * FROM vegetables
LEFT JOIN fruits ON vegetables.price = fruits.price)
UNION
(SELECT * FROM vegetables
RIGHT JOIN fruits ON vegetables.price = fruits.price);
+------+------------+-------+------+----------+-------+
| id   | name       | price | id   | name     | price |
+------+------------+-------+------+----------+-------+
|    1 | krastavici |     4 | NULL | NULL     |  NULL |
|    2 | domati     |     5 | NULL | NULL     |  NULL |
|    3 | kartofi    |     3 |    1 | banani   |     3 |
| NULL | NULL       |  NULL |    2 | iagodi   |   2.5 |
| NULL | NULL       |  NULL |    3 | chereshi |     7 |
+------+------------+-------+------+----------+-------+
5 rows in set (0.00 sec)

Редовете са точно 5, а това е именно каквото очаквахме от FULL JOIN. Този метод върши работа в почти всички случай, но за съжаление НЕ покрива 100% стандарта на определението за FULL JOIN. Проблемът е, че UNION премахва всички дублиращи се редове, а FULL JOIN не го прави ако има такива. За да се демонстрира това трябва в една от таблиците да има дублиращи се редов – в този случай по стандарта за FULL JOIN ще трябва този ред да излезе два пъти, а с горната реализация няма да се получи. Eто един пример:

INSERT INTO vegetables (`id`, `name`, `price`)
VALUES (NULL, 'krastavici', 4);

SELECT * FROM vegetables;
+----+------------+-------+
| id | name       | price |
+----+------------+-------+
|  1 | krastavici |     4 |
|  2 | domati     |     5 |
|  3 | kartofi    |     3 |
|  4 | krastavici |     4 |
+----+------------+-------+
4 rows in set (0.00 sec)

(SELECT vegetables.name, fruits.name FROM vegetables
LEFT JOIN fruits ON vegetables.price = fruits.price)
UNION
(SELECT vegetables.name, fruits.name FROM vegetables
RIGHT JOIN fruits ON vegetables.price = fruits.price);
+------------+----------+
| name       | name     |
+------------+----------+
| krastavici | NULL     |
| domati     | NULL     |
| kartofi    | banani   |
| NULL       | iagodi   |
| NULL       | chereshi |
+------------+----------+
5 rows in set (0.00 sec)

Виждаме, че в резултата има само едни ‘krastavici’, а при истински FULL JOIN трябваше да са две. Този проблем няма да се реши и с UNION ALL, защото в този случай ще се появят други дублиращи се редове, които НЕ трябва да присъстват:

(SELECT vegetables.name, fruits.name FROM vegetables
LEFT JOIN fruits ON vegetables.price = fruits.price)
UNION ALL
(SELECT vegetables.name, fruits.name FROM vegetables
RIGHT JOIN fruits ON vegetables.price = fruits.price);
+------------+----------+
| name       | name     |
+------------+----------+
| krastavici | NULL     |
| domati     | NULL     |
| kartofi    | banani   |
| krastavici | NULL     |
| kartofi    | banani   |
| NULL       | iagodi   |
| NULL       | chereshi |
+------------+----------+
7 rows in set (0.00 sec)

Тук „krastavici“ се появяват два пъти, както трябва да бъде, но реда „kartofi | banani“ се появява два пъти, а не трябва да бъде така! Затова за реализация на FULL JOIN се използва друг подход, който е модификация на последния:

(SELECT vegetables.name, fruits.name FROM vegetables
LEFT JOIN fruits ON vegetables.price = fruits.price)
UNION ALL
(SELECT vegetables.name, fruits.name FROM vegetables
RIGHT JOIN fruits ON vegetables.price = fruits.price
WHERE vegetables.price IS NULL);
+------------+----------+
| name       | name     |
+------------+----------+
| krastavici | NULL     |
| domati     | NULL     |
| kartofi    | banani   |
| krastavici | NULL     |
| NULL       | iagodi   |
| NULL       | chereshi |
+------------+----------+
6 rows in set (0.00 sec)

С добавеното условие WHERE ние премахнахме редовете, които вече са общи за двете таблици. Така вече имаме напълно функционална FULL JOIN заявка!

В по-старите версии на MySQL, където UNION не съществува, реализацията се прави чрез създаването на трета временна таблица. Няма да се спираме на това решение.

CREATE DATABASE unions;

CREATE TABLE vegetables(
	`id` INT NOT NULL AUTO_INCREMENT,
	`name` VARCHAR(255) NULL DEFAULT NULL,
	`price` DOUBLE NULL DEFAULT NULL,
	PRIMARY KEY (`id`)
);

CREATE TABLE fruits(
	`id` INT NOT NULL AUTO_INCREMENT,
	`name` VARCHAR(255) NULL DEFAULT NULL,
	`price` DOUBLE NULL DEFAULT NULL,
	PRIMARY KEY (`id`)
);

INSERT INTO vegetables(`id`, `name`, `price`)
VALUES 	(NULL, 'krastavici', 4.00),
	(NULL, 'domati', 5.00),
	(NULL, 'kartofi', 3.00);

INSERT INTO fruits(`id`, `name`, `price`)
VALUES 	(NULL, 'banani', 3.00),
	(NULL, 'iagodi', 2.50),
	(NULL, 'chereshi', 7.00);

Сега искаме да създадем таблица, която да изведе имената както на плодовете, така и на зеленчуците. Познатия досега вариант е с използване на JOIN, но така таблицата ще бъде с две колони. Ако искаме резултата да е подреден в една колона, то използваме UNION:

(SELECT name as Fruits_and_veggies
FROM vegetables)
UNION
(SELECT name
FROM fruits);
+--------------------+
| Fruits_and_veggies |
+--------------------+
| krastavici         |
| domati             |
| kartofi            |
| banani             |
| iagodi             |
| chereshi           |
+--------------------+
6 rows in set (0.00 sec)

Както виждате името на колоната се приема за името от първата таблица. Естествено можем да направим UNION и по две колони:

(SELECT name as Fruits_and_veggies, price
FROM vegetables)
UNION
(SELECT name, price
FROM fruits);
+--------------------+-------+
| Fruits_and_veggies | price |
+--------------------+-------+
| krastavici         |     4 |
| domati             |     5 |
| kartofi            |     3 |
| banani             |     3 |
| iagodi             |   2.5 |
| chereshi           |     7 |
+--------------------+-------+
6 rows in set (0.00 sec)

Не е задължително данните да са от един и същ тип. Важно е обаче броя на колоните от първия SELECT да съвпада с броя на колоните на втория! В противен случай няма как да се извърши обединението.

След като натрупате опит в използването на UNION рано или късно ще достигнете до един първоначално изглеждащ странен ефект – дублиращите се редове автоматично се премахват! Ето един пример:

(SELECT price
FROM vegetables)
UNION
(SELECT price
FROM fruits);
+-------+
| price |
+-------+
|     4 |
|     5 |
|     3 |
|   2.5 |
|     7 |
+-------+
5 rows in set (0.00 sec)

Знаем, че имаме общо 6 плода и зеленчука в таблиците, а в резултата от цените излязоха само 5. Това е така, защото цената на banani и kartofi е една и съща и UNION е премахнал дублиращите се редове. Ако това предизвиква потенциален проблем във вашата заявка, то трябва да използвате допълнителната дума ALL:

(SELECT price
FROM vegetables)
UNION ALL
(SELECT price
FROM fruits);
+-------+
| price |
+-------+
|     4 |
|     5 |
|     3 |
|     3 |
|   2.5 |
|     7 |
+-------+
6 rows in set (0.00 sec)

Естествено възможно е UNION да е част от под-заявка (например вложен SELECT). Затова ограждането на заявките в скоби не е задължително, но е силно препоръчително.

1. IF-ELSE:

Операторите IF-ELSE имат следната структура:

IF <условие>
   THEN <заявки>;
   ELSE <заявки>;
END IF;

Нека демонстрираме с един пример – процедура, на която подаваме параметри сума и номер на акаунт. Процедурата връща резултат „1″ ако в акаунта има повече пари от посочените или „0″ в противен случай:

mysql> DELIMITER |

mysql> CREATE PROCEDURE check_availability(IN acc INT, IN money DOUBLE)
       BEGIN

              DECLARE acc_avail INT;

              SELECT amount
              INTO acc_avail
              FROM accounts
              WHERE id = acc;

              IF (acc_avail >= money)
                     THEN SELECT 1;
                     ELSE SELECT 0;
              END IF;

       END
       |
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

mysql> SELECT id, amount FROM accounts WHERE id = 5;
+----+--------+
| id | amount |
+----+--------+
|  5 | 191.98 |
+----+--------+
1 row in set (0.00 sec)

mysql> CALL check_availability(5, 200);
+---+
| 0 |
+---+
| 0 |
+---+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

mysql> CALL check_availability(5, 150);
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

Виждате, че се получи точно желания резултат – в акаунт №5 има точно 191.98. Когато попитаме процедурата дали има 200 тя връща резултат 0, а когато я попитаме дали има 150 връща резултат 1.

Искаме да обърнем внимание на заявката „DECLARE x INT“. Чрез нея ние дефинираме т.нар. локална променлива за процедурата. Тя е валидна само вътре в процедурата и се изтрива след нейното приключване. Виждате, че в случая я инициализирахме като резултат от временна таблица (SELECT -> INTO).

Трябва много да внимавате при евентуално подаване на NULL стойности. Както и при обикновените заявки, всяко сравнение с NULL стойност връща резултат FALSE.

2. CASE:

CASE е аналог на операторът за многовариантен избор switch в езика за програмиране C. Синтаксисът е следния:

CASE <променлива>
   WHEN <условие>
      THEN <заявки>;
   WHEN <условие>
      THEN <заявки>;
   ...
   ELSE <заявки>
END CASE;

Частта ELSE се достига тогава, когато нито едно от условията по-горе не е изпълнено.

Нека демонстрираме с пример – процедура, която по зададен номер на акаунт връща името на типа му:

mysql> DELIMITER |
mysql>
mysql> CREATE PROCEDURE acc_type(IN acc INT)
       BEGIN

              DECLARE acc_t TINYINT;

              SELECT type
              INTO acc_t
              FROM accounts
              WHERE id = acc;

              CASE acc_t
              WHEN 1 THEN
                     SELECT "3 months deposit";
              WHEN 2 THEN
                     SELECT "Annual deposit";
              ELSE
                     SELECT "Unknown account";
              END CASE;

       END
       |
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

mysql> SELECT id, type FROM accounts WHERE id = 6 OR id = 7;
+----+------+
| id | type |
+----+------+
|  6 |    2 |
|  7 |    1 |
+----+------+
2 rows in set (0.00 sec)

mysql> CALL acc_type(6);
+----------------+
| Annual deposit |
+----------------+
| Annual deposit |
+----------------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

mysql> CALL acc_type(7);
+------------------+
| 3 months deposit |
+------------------+
| 3 months deposit |
+------------------+
1 row in set (0.00 sec)
Query OK, 0 rows affected (0.00 sec)

3. WHILE:

Процедурите в MySQL добиват още по-голяма сила с наличието на цикли. Първият и може би най-популярен е WHILE:

WHILE <условие>
DO
   <заявки>;
END WHILE;

Например следната процедура ще изведе сумите по акаунти на всички клиенти в зададен диапазон (x,y):

mysql> DELIMITER |

mysql> CREATE PROCEDURE check_clients(IN x INT, IN y INT)
       BEGIN

              DECLARE iterator INT;

              SET iterator = x;

              WHILE (iterator >= x AND iterator <= y)
              DO
                     SELECT id, amount
                     FROM accounts
                     WHERE id = iterator;

                     SET iterator = iterator + 1;
              END WHILE;

       END
       |
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

mysql> CALL check_clients(5,9);

+----+--------+
| id | amount |
+----+--------+
|  5 | 191.98 |
+----+--------+
1 row in set (0.00 sec)

+----+---------+
| id | amount  |
+----+---------+
|  6 | 1220.00 |
+----+---------+
1 row in set (0.00 sec)

+----+--------+
| id | amount |
+----+--------+
|  7 | 133.48 |
+----+--------+
1 row in set (0.00 sec)

+----+--------+
| id | amount |
+----+--------+
|  8 | 256.41 |
+----+--------+
1 row in set (0.00 sec)

+----+---------+
| id | amount  |
+----+---------+
|  9 | 1331.50 |
+----+---------+
1 row in set (0.02 sec)

Query OK, 0 rows affected (0.02 sec)

4. REPEAT-UNTIL:

Цикълът е с абсолютно същото действие както WHILE, с изключение, че ако условието е погрешно в самото начало, то въпреки това тялото на цикъла ще се изпълни поне веднъж:

REPEAT
   <заявки>;
UNTIL <условие>;
END REPEAT;

Този вид цикъл е малко популярен и рядко намира приложение. Затова няма да го разглеждаме подробно с пример.

Задача: Преработете процедурата за прехвърляне на пари от един акаунт в друг като направите така, че ако първият акаунт няма достатъчно пари, то да се изведе съобщение за грешка.

mysql> DELIMITER |

mysql> CREATE PROCEDURE show_customers()
    -> BEGIN
    ->  SELECT * FROM customers;
    -> END
    -> |
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

mysql> CALL show_customers();
+----+-------------------+---------+----------+
| id | name              | address | bank_mgr |
+----+-------------------+---------+----------+
|  1 | Todor Ivanov      | NULL    |        1 |
|  2 | Petko Stoianov    | NULL    |        1 |
|  3 | Neno Nenov        | NULL    |     NULL |
|  4 | Mariana Zaharieva | NULL    |        3 |
|  5 | Elica Zaharieva   | NULL    |        3 |
|  6 | Atanas Petrov     | NULL    |        4 |
|  7 | Ivan Ivanov       | NULL    |        4 |
|  8 | Zlatomir Petrov   | NULL    |        4 |
|  9 | Mihail Ivchev     | NULL    |        5 |
| 11 | Ivailo Ivanov     | NULL    |        7 |
| 12 | George Lucas      | NULL    |     NULL |
| 13 | George Harison    | NULL    |     NULL |
| 14 | Michael Jackson   | NULL    |     NULL |
| 15 | Tony Martin       | NULL    |     NULL |
| 16 | Tony McCarter     | NULL    |     NULL |
| 17 | Alexander Smith   | NULL    |       11 |
| 18 | Maria Smith       | NULL    |       11 |
| 19 | Alain Delrick     | NULL    |       12 |
| 20 | Devry Henry       | NULL    |       12 |
| 21 | Lenard Renne      | NULL    |       12 |
| 22 | Fontaine Rupert   | NULL    |       13 |
+----+-------------------+---------+----------+
21 rows in set (0.00 sec)

Query OK, 0 rows affected (0.02 sec)

Обърнете внимание на командата „DELIMITER“. Чрез първото й изпълнение указваме, че края на заявка вече няма да става с „;“, а с „|“. Това е нужно, защото при създаването на процедурата трябва да използваме символа „;“ при края на заявката SELECT. DELIMITER може да бъде всяка комбинация от символи.

Можем да създаваме процедури за изпълнение на повече от една заявка наведнъж. Ясно е обаче, че създаването на процедури с предварително дефинирани константни заявки е безсмислено. Бихме искали една процедура да изпълнява различни заявки, в зависимост от подадени към нея данни. За целта на помощ идват т.нар. параметри (parameters), които са много подобни на променливите в програмирането. Още по-добра аналогия може да се направи със потребителските сесии при програмиране в интернет (session variables). Нека демонстрираме параметрите в MySQL с елементарен пример с таблицата banks:

mysql> USE banks;
Database changed

mysql> SET @cust_name = 'Ivan Ivanov';
Query OK, 0 rows affected (0.02 sec)

mysql> SELECT * FROM CUSTOMERS
       WHERE name = @cust_name;
+----+-------------+---------+----------+
| id | name        | address | bank_mgr |
+----+-------------+---------+----------+
|  7 | Ivan Ivanov | NULL    |        4 |
+----+-------------+---------+----------+
1 row in set (0.05 sec)

Казахме, че има аналогия с променливи в потребителски сесии – това е така, защото тази променлива е валидна само за текущата връзка. При приключване на връзката тя ще бъде унищожена.

Процедурите могат да достъпват параметри по три различни начина:

1. IN:

mysql> DELIMITER |

mysql> CREATE PROCEDURE proc_in(IN var VARCHAR(255))
BEGIN
   SET @cust_name = var;
END
|
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

mysql> CALL proc_in('Atanas Petrov');
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM customers WHERE name = @cust_name;
+----+---------------+---------+----------+
| id | name          | address | bank_mgr |
+----+---------------+---------+----------+
|  6 | Atanas Petrov | NULL    |        4 |
+----+---------------+---------+----------+
1 row in set (0.02 sec)

Виждаме как към процедурата подадохме параметър и чрез него променихме стойността на променливата, която беше дефинирана глобално.

Трябва да знаете, че ако към IN параметър на процедура подадете параметър вместо конкретна стойност и го промените вътре в процедурата, то този параметър ще се върне в първоначалното си състояние след приключване на процедурата. Можете да си направите аналогия с предаването на параметър към функция по стойност от програмирането на C++.

2. OUT:

mysql> DELIMITER |

mysql> CREATE PROCEDURE proc_out(OUT var VARCHAR(255))
    -> BEGIN
    ->    SET var = 'Todor Ivanov';
    -> END
    -> |
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

mysql> CALL proc_out(@cust_name);
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM customers WHERE name = @cust_name;
+----+--------------+---------+----------+
| id | name         | address | bank_mgr |
+----+--------------+---------+----------+
|  1 | Todor Ivanov | NULL    |        1 |
+----+--------------+---------+----------+
1 row in set (0.00 sec)

Тук подадохме променливата като входен параметър на процедурата и я променихме вътре във функцията. Виждате, че след приключването на процедурата глобалния параметър остана променен – това нямаше да стане, ако го бяхме направили с IN. Можете да си направите аналогия с подаването на параметър към функция като псевдоним в програмирането на C++.

3. INOUT:

mysql> SET @newvar = 'Petko Stoianov';
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER |
mysql> CREATE PROCEDURE proc_inout(INOUT var VARCHAR(255))
    -> BEGIN
    ->    SET var = @cust_name;
    -> END
    -> |
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

mysql> CALL proc_inout(@newvar);
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM customers WHERE name = @newvar;
+----+--------------+---------+----------+
| id | name         | address | bank_mgr |
+----+--------------+---------+----------+
|  1 | Todor Ivanov | NULL    |        1 |
+----+--------------+---------+----------+
1 row in set (0.00 sec)

Виждаме, че променливата @newvar беше със стойност ‘Petko Stoianov’, но след изпълнението на процедурата я променихме със стойността на @cust_name (‘Todor Ivanov’). Разликата между OUT и INOUT методите е, че при INOUT параметъра трябва да бъде дефиниран глобално преди извикването на функцията – при OUT не е така (ако не съществува ще бъде създаден).

Сега вече можем да създаваме и по-смислени процедури. Нека дадем един пример – процедура, която премества пари от един акаунт в друг. В случая ще използваме IN входен параметър (в процедурата не променяме стойностите на параметри):

mysql> USE banks;
Database changed

mysql> DELIMITER |

mysql> CREATE PROCEDURE transfer_money(acc_in INT, acc_out INT, money DOUBLE)
       BEGIN
              START TRANSACTION;

              UPDATE accounts
              SET amount = amount - money
              WHERE id = acc_out AND amount >= money;

              UPDATE accounts
              SET amount = amount + money
              WHERE id = acc_in;

              COMMIT;

       END
       |
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;

Ето как можем да преместим 20 лева от акаунт номер 5 в акаунт номер 6:

mysql> SELECT id, amount
       FROM accounts
       WHERE id = 5 OR id = 6;
+----+---------+
| id | amount  |
+----+---------+
|  5 |  211.98 |
|  6 | 1200.00 |
+----+---------+
2 rows in set (0.00 sec)

mysql> CALL transfer_money(6, 5, 20);
Query OK, 0 rows affected (0.06 sec)

mysql> SELECT id, amount
       FROM accounts
       WHERE id = 5 OR id = 6;
+----+---------+
| id | amount  |
+----+---------+
|  5 |  191.98 |
|  6 | 1220.00 |
+----+---------+
2 rows in set (0.00 sec)

В следващата статия ще покажем как можем да дефинираме и използваме променливи вътре в процедура.

mysql> USE banks;
Database changed

mysql> SELECT amount FROM accounts
WHERE id = 1;
+--------+
| amount |
+--------+
| 306.38 |
+--------+
1 row in set (0.00 sec)

Сега нека напишем заявка UPDATE, с която искаме да изтеглим 500 лева, но така, че ако искаме да няма такава наличност, то заявката да не се изпълни:

mysql> UPDATE accounts SET amount = amount - 500 WHERE id = 1 AND amount >= 500; Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> SELECT amount FROM accounts
WHERE id = 1;
+--------+
| amount |
+--------+
| 306.38 |
+--------+
1 row in set (0.00 sec)

Нека сега стартираме две връзки към базата от данни и да започнем транзакции. С тези транзакции ние ще се опитаме да изтеглим два пъти по 250 лева от акаунт с id = 1:

Виждаме, че втората връзка не върна резултат – тя стои в „спящ“ (idle) режим. Това е така, защото сървъра знае, че в този момент друга транзакция все още не е приключила, тоест резултатът от нея все още не е записан. Така втората връзка все още не „вижда“, че вече сумата в акаунта е намалена и ако вземе 250 лева, то банката ще изгуби пари. Затова при стартиране на транзакция се прави т.нар. „заключване“ (lock).

Нека сега приключим първата транзакция:

Виждаме, че това се отрази моментално във втората връзка. Както очаквахме там UPDATE не се направи, защото в акаунта вече няма достатъчно пари (те бяха взети от първата връзка).

Същото заключване на транзакции важи и за INSERT заявки. Нека създадем една примерна елементарна база от данни:

mysql> CREATE DATABASE locks;
Query OK, 1 row affected (0.00 sec)

mysql> USE locks;
Database changed

mysql> CREATE TABLE test(
                     val INT
       ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.14 sec)

mysql> INSERT INTO test
       VALUES (1), (2);
Query OK, 2 rows affected (0.06 sec)
Records: 2  Duplicates: 0  Warnings: 0

Нека сега стартираме две транзакции, с които искаме да прочетем най-голямата стойност в колоната val и съответно добавят нова стойност с едно по-голяма от втората:

Виждаме, че отново втората транзакция изчаква завършването на първата. В момента, в който извършим COMMIT в първата транзакция втората също ще изпълни заявката си:

Сега ще видим, че се е получило точно това, което искахме – първата транзакция е добавила val = 3, а втората val = 4:

Ако заключването на връзката не съществуваше, то и двете транзакции щяха да вмъкнат стойност „3″ и щяхме да имаме повтарящи се редове.

От тези примери трябва да си извадим важна бележка – важно е да приключваме транзакциите си възможно най-бързо. Ако ние се „бавим“, то други транзакции ще трябва да ни изчакват. В MySQL има стандартен timeout от няколко секунди (естествено може да бъде настройван чрез my.cnf/my.ini) за изчакване – ако дадена заявка е в режим „изчакване“ и този timeout бъде достигнат, то заявката ще пропадне.

Заключването на връзките важи за заявки UPDATE, INSERT и DELETE. По подразбиране то не е валидно за заявки от тип SELECT. MySQL обаче ни предоставя възможност да го правим ръчно:

SELECT <rows> FROM <table> FOR UPDATE;

В последния пример указваме, че данните, които са върнати от SELECT заявката, ще бъдат заключени. По този начин ако някоя друга транзакция се опита да чете или променя данните, то тя ще трябва да изчака изпълнението на първата започната.

По-слабо заключване е „LOCK IN SHARE MODE“, с което позволяваме на други транзакции да четат, но не и да променят данните. Чрез такова заключване сме сигурни, че прочетените данни ще бъдат най-новите налични в системата и никоя друга транзакция няма да ги промени междувременно:

SELECT <rows> FROM <table> LOCK IN SHARE MODE;

С последния пример при отваряне на втора връзка всички видове заявки ще бъдат блокирани в idle режим докато първата транзакция не завърши.

UPDATE accounts
SET amount = amount - 50
WHERE id = 1;

UPDATE accounts
SET amount = amount + 50
WHERE id = 2;

Какво обаче ще се случи ако например втората заявка не се изпълни (например възникне грешка)? Отговорът е, че парите ще бъдат изгубени. Тук се явява силата на транзакциите – те гарантират че ако някоя заявка не се изпълни, то данните ще бъдат възстановени в първоначален вид.

Групирането на заявки в транзакция се изпълнява изключително лесно. Единствено трябва да оградим данните с BEGIN (започване на транзакция) и COMMIT (край на транзакция):

BEGIN;

UPDATE accounts
SET amount = amount - 50
WHERE id = 1;

UPDATE accounts
SET amount = amount + 50
WHERE id = 2;

COMMIT;

Ако някоя от транзакциите пропадне, то се прави т.нар. ROLLBACK. За целта се използва innodb log файл, в който се записват старите данни преди изпълнението на всяка заявка. Естествено ние можем да правим ROLLBACK и сами. Например:

mysql> SELECT amount
FROM accounts
WHERE id = 1;
+--------+
| amount |
+--------+
| 106.38 |
+--------+
1 row in set (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE accounts
SET amount = amount - 50
WHERE id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> ROLLBACK;
Query OK, 0 rows affected (0.36 sec)

mysql> SELECT amount
FROM accounts
WHERE id = 1;
+--------+
| amount |
+--------+
| 106.38 |
+--------+
1 row in set (0.00 sec)

Виждате, че резултатите от заявката SELECT са едни и същи, тоест ROLLBACK е „върнал“ данните в първоначалния им вид преди заявката UPDATE.

Транзакциите трябва да отговарят на условие за консистентно четене. Това означава, че всеки SELECT чете данните записани точно след последния COMMIT. Ето един пример – отворили сме две връзки към базата данни. С едната започваме транзакция и правим UPDATE като даваме 200 лева на акаунт 1. След това във втората връзка искаме да проверим наличността на този акаунт:

След това с първата връзка завършваме транзакцията и отново проверяваме каква е стойността във втората връзка:

Важно е да споменем, че при InnoDB всяка заявка, която НЕ участва в блокове „BEGIN – COMMIT“ е автоматично записана, т.е. можем да приемем, че единичните заявки са завършени транзакции сами по себе си.

В следващата статия ще разгледаме „заключвания“ с цел синхронизация на транзакции.

Забележка: За стартиране на транзакция можете да използвате и по-популярната сред останалите бази данни „START TRANSACTION“ команда.

По настройките има някои съществени разлики между Linux-базираните платформи и Windows варианта. Понеже MySQL се използва по-често под Linux и FreeBSD, то ще разгледаме предимно настройки за тези платформи. Някои от тях може би не са валидни под Windows.

В MySQL има изключително много променливи за настройка. Някои от тях обаче са изключително важни за общото бързодействие на системата. За да видите списък на променливите и техните стойности използвайте следната команда:

show variables;

За да видите работните процеси:

show status;

Сега ще разгледаме някои от най-важните променливи:

1. key_buffer_size – Изключително важна настройка за MyISAM таблици. Обикновено при първоначална инсталация стойността на тази променлива се слага грубо на около 30% от големината на RAM паметта на системата при положение, че ще се използва предимно MyISAM. По-фините настройки зависят от големината на индексите и информацията. В по-новите системи се използва предимно InnoDB, но въпреки това все пак трябва да се заделят като минимум 16MB key_buffer_size, защото той ще се използва за създаване на временни таблици. Ако тази променлива е с недостатъчна големина, то ще се използват дискови операции, които забавят системата значително;

2. innodb_buffer_pool_size – Когато става дума да InnoDB таблици, то стойността на този параметър е изключително важен. В RAM паметта се кешират и данните и индексите. Поради тази причина ако имате само бази данни от тип InnoDB, то не е неоправдано да заделите изключително голямо количество за innodb_buffer_pool_size – над 30% от паметта на системата.

3. innodb_additional_mem_pool_size – Тази настройка няма реален ефект върху производителността. Използва се за специфични нужди на InnoDB. Една стойност от около 20MB е добра за старт на натоварен сървър.

4. table_cache – Отварянето на таблици е бавна операция. Когато дадена таблица се достъпва, тя се маркира като „currently in use“ в своя заглавен файл (header file). Затова е хубаво да имаме достатъчно голям table_cache, за да можем да имаме колкото се може повече отворени таблици наведнъж. Ако в системата ви има не повече от 300 таблици, то стойност на table_cache около 1000 може би ще бъде достатъчна. Имайте в предвид, че всяка една връзка към базата данни отваря поне една таблица. При изключително натоварени бази данни стойността на table_cache може да се направи огромна.

5. query_cache_size – Ако приложението ви изключително много чете данни, то е добре да си направите кеш на заявките и така да облекчите тяхната „компилация“. Тук обаче в никакъв случай не трябва да се прекалява, защото практиката показва влошаване при преоразмеряване. Стойности от порядъка на 32 до 128MB са нормални. Обикновено се гледа стойността от статистиките на сървъра „cache hit ratio“ и ако той е нисък, то стойността на query_cache_size се увеличава.

6. thread_cache – Създаването и унищожаването на нишки при връзка и изход от базата данни също отнема ресурси. Създаването на кеш за нишките често може да подобри бързината на инициализация. Обикновено стойността трябва да варира между 12 и 16. Увеличава се повече само при изключително натоварени сървъри.

7. sort_buffer – Увеличава скоростта на операциите myisamchk. Може да бъде изключително полезна при таблици с често сортиране.

8. read_rnd_buffer_size – Използва се при четене на вече сортирани колони от таблици. Отново ако имате често сортиране, то увеличавайки стойността ще увеличите и бързодействието. Имайте в предвид, че за разлика от key_buffer_size и table_cache, тази памет се заделя отделно за всяка една нишка. Обикновено правилото е да заделите по 1KB за всеки 1MB от рам паметта на сървъра.

9. innodb_log_file_size – Ако използвате много транзакции, то тази стойност е изключително важна. По-голяма стойност ще увеличи изключително много бързодействието, но за сметка на това увеличава времето за възстановяване след неуспешна транзакция, т.е. трябва да се планира според системата. Поради таци причина препоръчителните стойности могат да варират между 64M и 512M.

10. innodb_log_buffer_size – Обикновено тази променлива не се променя и се използва стойността й по подразбиране. Единствената причина за увеличаване може да е ако имате много заявки от тип UPDATE и полета от тип TEXT/BLOB. Този буфер така или иначе се изтрива всяка секунда и затова стойности над 8MB до 12MB не са оправдани и ще дадат само разход на памет. При по-малки системи дори можете да занижите под стойността по подразбиране.

11. innodb_flush_log_at_trx_commit – Ако използвате InnoDB, то тази променлива може да окаже изключителна разлика в бързодействието, но за сметка на това е опасна за цялостта на данните. По подразбиране то е 1, т.е. за всеки COMMIT на заявка или всяка заявка извън транзакция (т.е. не участваща в транзакция) ще трябва да се изчиства log файла на диска. Най-често проблем се вижда при преминаване на едно приложение от MyISAM към InnoDB, защото MyISAM не използва транзакции. Ако сложите стойност 2, то ще се изчиства само кеша на операционната система. Стойност 0 няма да изчиства кеша и бързодействието се повишава значително, но риска от загуба на информация при непредвидено спиране на системата е огромен. При стойност 2 може да се изгуби информация само при блокиране на операционната система.

12. tmp_table_size – Ако често използвате временни таблици е добре да предвидите повече рам памет, за да не се записват на хард диска.

13. myisam_sort_buffer_size – Използва се при REPAIR TABLE, CREATE TABLE и CREATE INDEX. Тези операции са редки и често можете да намалите тази стойност до минимум.

14. max_tmp_tables – Колко временни таблици могат да бъдат използвани едновременно? Отговорът е, че зависи от приложенията.

15. max_tmp_tables – Колко рам памет да бъде заделена за временните ви таблици? Ако работите с BLOB/TEXT, то може би доста. Ако паметта е недостатъчна е ясно, че ще се прибегне до дискови операции.

16. max_connections – Това е най-опасната опция. За всяка една връзка към базата данни се заделя голямо количество памет (всички буфери). Ако преоразмерите тази стойност, то обикновено няма да има проблем. При пикови моменти обаче може да се надхвърли физическата оперативна памет и това да доведе до изключително слаба производителност за всички нишки. Ако пък стойността се направи малка, то може лесно да се достигне лимита и много клиентски приложения да бъдат блокирани. Затова се казва, че max_connections е аларма за upgrade на системата. Обикновено тази стойност трябва да се държи на 200% от средната стойност на едновременни връзки към базата данни от статистиката. Ако статистическите данни покажат увеличаване на едновременните връзки към базата данни, а физическото количество памет ще бъде прехвърлено при увеличаване на max_connections, то трябва да сложите още рам на сървъра.

17. read_buffer_size – Ако са ви нужни бързи „full table scan“, т.е. заявки без използване на index, то стойността на read_buffer_size трябва да е голяма. На теория е така, но на практика се оказва, че поради външни фактори (най-често операционна система) производителността не се увеличава. Статистиката сочи, че дори при доста голяма таблица от около 5 000 000 записа, стойности над 128KB на read_buffer_size ще намалят производителността, вместо да я подобрят!

18. join_buffer_size – Буфера за правене на JOIN между таблици е стандартно доста малък, като се има в предвид, че тъй или иначе не е добра идея да се правят големи JOIN връзки между таблици. Обикновено администраторите предпочитат да го увеличат до около 1MB.

19. thread_stack – Обикновено не е полезно да пипате тази променлива (в никакъв случай не я намалявайте). При Linux системи увеличаването й няма да подобри почти нищо, а само ще изразходва повече рам. При FreeBSD може да се забележат минимални подобрения. Това ще бъде една от последните опции, които би трябвало да гледате за оптимизация.

20. max_packet_size – Стойност, която трябва да се променя спрямо базите данни в системата. Увеличаването й ще подобри скоростта, като намали броят на пакетите, но за сметка на това увеличава значително изискването за повече рам памет. Ако не се качват големи файлове в базите данни в системата, то дръжте тази стойност ниска.

Всичко казано дотук е добро, но все пак трябва да се съобразим с размера на рам паметта на сървъра. Общата формула(*) е:

Рам паметта на сървъра >=
рам паметта използвана от операционната система +
рам паметта използвана от другите програми (Apache, mail server, и т.н.)
рам паметта използвана от програмите на MySQL (средно 32MB) +
key_buffer_size +
innodb_buffer_pool_size +
innnodb_additional_memory_pool_size +
innodb_log_buffer_size +
max_tmp_tables * tmp_table_size +
query_cache_size +
3 * myisam_sort_buffer_size +
max_connections * (
	read_buffer_size +
	join_buffer_size +
	read_rnd_buffer_size +
	thread_stack +
	2*max_packet_size
)

* – формулата е взета от следната статия:
http://www.paragon-cs.com/wordpress/category/key_buffer_size/

Имайте в предвид, че повечето от казаните по-горе неща важат за сървъри, които работят предимно с бази данни. Ако имате други приложения, които натоварват сървъра много, то трябва да се съобразявате с тях.

Има и още някои тънкости, свързани с кеша. Например query_cache прави разлика между малки и големи букви. Например заявките „SELECT * FROM banks“ и „select * from banks“ за query_cache ще са две различни заявки. Това е и една от причините да спазваме някакви конвенции при програмирането на бази данни.

При силно използване на MyISAM е добре да гледате т.нар. „key_buffer_size hit ratio“. То се изчислява по следната формула:

Key_reads/Key_read_requests

Ако стойността е над 0,01, то е добре да помислите за увеличаване на key_buffer_size.

Накрая е важно да споменем и променливата за „прекъсване“ (timeout). Wait_timeout е променлива, която контролира „спящите“ връзки. Често програмистите на приложения забравят да затворят връзките си към базата данни. Това естествено рефлектира с изразходване на памет, което никак не е добре. Намаляване на wait_timeout ще затваря спящите връзки по-бързо. Обикновено предпочитанията на администраторите са в интервала 10 до 15 секунди. Имайте в предвид обаче, че намаляването на wait_timeout може да рефлектира в нужда от увеличаване на max_connections. Тук в голяма помощ идва thread_cache променливата, за която писахме по-горе.

Също така опитайте оптимизация по следната формула:

table_cache = opened table / max_used_connection

Трябва да знаете, че няма стриктна формула, по която нашия MySQL сървър да работи най-добре. Обикновено настройките са един постоянен и продължителен процес. Добрите администратори непрекъснато следят системата си и я „тунинговат“ според натоварването.

В тази статия сме дали само най-важните променливи, свързани с производителност на системата. Имайте в предвид, че общо за MySQL 5.1 общо променливите са над 260 (естествено не всички са използваеми и не всички свързани с производителност)…

Присъствието или отсъствието на индекс няма ефект върху крайния резултат на заявките. Единствената разлика е в евентуалното повишено бързодействие (при по-големи таблици може разликата да е огромна). Важно е обаче да създаваме индексите правилно, защото от това зависи дали системата ще ги използва или не.

За да демонстрираме повишеното бързодействие сме изпълнили една проста заявка на доста бавен компютър.:

mysql> SELECT * FROM accounts
    -> WHERE customer_id = 11;
+----+--------+------+-----------+-------------+
| id | amount | type | branch_id | customer_id |
+----+--------+------+-----------+-------------+
| 12 |  99.18 |    1 |         2 |          11 |
+----+--------+------+-----------+-------------+
1 row in set (0.30 sec)

Нека сега създадем индекс по колоната, която участва в условието WHERE на оператора SELECT и изпълним заявката отново:

mysql> CREATE INDEX accounts_customer_id
    -> ON accounts(customer_id);
Query OK, 27 rows affected (1.93 sec)
Records: 27  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM accounts
    -> WHERE customer_id = 11;
+----+--------+------+-----------+-------------+
| id | amount | type | branch_id | customer_id |
+----+--------+------+-----------+-------------+
| 12 |  99.18 |    1 |         2 |          11 |
+----+--------+------+-----------+-------------+
1 row in set (0.03 sec)

Виждате, че разликата в бързодействието е 10 пъти! За тази тестова постановка изтрих базата данни, рестартирах сървъра и я създадох наново, защото обикновено системата за управление на бази данни си пази cache на вече използвани заявки. Също така трябва да отбележа, че в този тестов пример колоната customer_id НЕ Е foreign key. Системата за управление на бази данни обикновено създава автоматично индекси по първични и външни ключове.

Обикновено за структура от данни на индексите се използва BTREE (бинарно дърво). При различните системи има възможности за използване на алтернативни структури, но това не е задължително.

Истината е, че индексите не винаги са подходящи. В редица случаи те може да навредят на производителността на системата. Това се получава ако имаме таблици, върху които често правим заявки от тип UPDATE, INSERT и DELETE, то всеки път индексът трябва да се обновява. Затова таблици, в които често се добавят данни и рядко се четат такива е по-добре да не използваме индекс.

Същото важи и за индексите върху колони с много повтарящи се редове. Ако имаме такава колона, в която данните се повтарят изключително много, то по-добре да не създаваме индекс, защото ефектът ще бъде на забавяне на системата. Създавайте предимно индекси върху колони с ключ UNIQUE.

Ако вашите таблици се обновяват периодично (например в края на месеца се обновява таблица със статистики), то следвайте следната последователност:
- Изтриване на индекса;
- Обновяване на данните;
- Създаване на индекса отново.

Ето още един пример за създаване и изтриване на индекс:

mysql> CREATE INDEX customers_name
    -> ON customers(name);
Query OK, 22 rows affected (0.17 sec)
Records: 22  Duplicates: 0  Warnings: 0

mysql> DROP INDEX customers_name
    -> ON customers;
Query OK, 22 rows affected (0.15 sec)
Records: 22  Duplicates: 0  Warnings: 0

Можете лесно да се досетите, че е възможно да направите повече от един индекс върху една таблица. В последствие когато правите заявки SELECT MySQL обикновено се досеща кой индекс е най-подходящ при заявката. Въпреки това е възможно вие сами да укажете кой индекс да се използва:

mysql> SELECT * FROM mytable
    -> USE INDEX (col1index, col2index)
    -> WHERE col1 = 1 AND col2 = 2;

Ако пък желаете е възможно да укажете кой индекс да НЕ се използва чрез командата „IGNORE INDEX“:

mysql> SELECT * FROM mytable
    -> IGNORE INDEX (col1index)
    -> WHERE col1 = 1 AND col2 = 2;

Виртуалните таблици имат и редица други предимства:
- Различните потребители в системата могат да виждат едни и същи данни по различен начин;
- Удобни са за ограничаване се достъпа на потребителите до базовата таблица и така те могат да достъпват само данните, които извежда виртуалната таблица.

Виртуална таблица се създава чрез операторът CREATE VIEW:

CREATE VIEW <име>(<имена на колони>)
AS SELECT <имена на колони> ... ;

Във вложения оператор SELECT не може да се използва ORDER BY и UNION. Важно е да има съответствие между върнатите колони от оператора SELECT и изброените след името на VIEW.

Пример: Създаване на виртуална таблица с данните на служителите на банка Bulbank:

 CREATE VIEW bulbank_employees
 AS SELECT * FROM employees
    WHERE branch_id IN(
       SELECT id FROM branches
       WHERE bank_code IN(
          SELECT code FROM banks
          WHERE name = "Bulbank"
       )
    );

Сега можем да го използваме също както обикновена таблица:

mysql> SELECT * FROM bulbank_employees;
+----+-----------------+-----------+
| id | name            | branch_id |
+----+-----------------+-----------+
|  1 | Ivan Ivanov     |         1 |
|  3 | Mihail Zahariev |         1 |
|  4 | Milen Stoilov   |         2 |
|  5 | Svilen Petrov   |         2 |
|  6 | Ilian Stoianov  |         2 |
|  7 | Petar Petrov    |         2 |
+----+-----------------+-----------+
6 rows in set (0.00 sec)

Можем да изпълняваме и заявки от тип INSERT, UPDATE и DELETE – те ще бъдат трансформирани автоматично от системата за управление на бази данни върху базовата таблица.

Ако в операторът SELECT участва агрегатна функция или GROUP BY, то става напълно необновяемо. Изобщо използването на INSERT, UPDATE и DELETE при VIEW не се препоръчва. Най-често VIEW се използва „само за четене“ и съответно потребителите се рестриктират да имат само права SELECT върху тези таблици.

За изтриването на VIEW става чрез оператора DROP VIEW:

DROP VIEW bulbank_employees CASCADE;

Ключовата дума CASCADE означава, че ако има производно на това VIEW (т.е. VIEW създадено чрез изтриваното VIEW), то също ще бъде изтрито. Алтернативата е с ключова дума RESTRICT, където ако има производно VIEW, то ще бъде върната грешка. По принцип не е добра идея да създавате производни една на друга виртуални таблици. Стойността по подразбиране на DROP VIEW e CASCADE.

DELETE FROM <таблица>
WHERE <условие>;

Нека демонстрираме един пример с базата от данни „banks“. Нека видим първо списък на акаунтите:

mysql> SELECT * FROM accounts;
+----+----------+------+-----------+-------------+
| id | amount   | type | branch_id | customer_id |
+----+----------+------+-----------+-------------+
|  1 |   156.38 |    2 |         1 |           1 |
|  2 |   136.22 |    1 |         1 |           2 |
|  3 |    42.98 |    1 |         1 |           3 |
|  4 |  1236.33 |    1 |         1 |           4 |
|  5 |   211.98 |    2 |         1 |           5 |
|  6 |  1200.00 |    2 |         2 |           6 |
|  7 |   133.48 |    1 |         2 |           7 |
|  8 |   256.41 |    2 |         2 |           8 |
|  9 |  1331.50 |    2 |         2 |           9 |
| 10 |   116.88 |    2 |         2 |          10 |
| 11 |   200.91 |    1 |         2 |          10 |
| 12 |    99.18 |    1 |         2 |          11 |
| 13 |  6712.52 |    1 |         3 |          12 |
| 14 | 12000.56 |    1 |         3 |          12 |
| 15 |   322.99 |    2 |         3 |          12 |
| 16 |   991.63 |    1 |         3 |          13 |
| 17 |   559.32 |    2 |         3 |          14 |
| 18 |   680.13 |    1 |         3 |          15 |
| 19 |   532.57 |    1 |         3 |          15 |
| 20 |   402.26 |    1 |         3 |          16 |
| 21 |  1536.91 |    2 |         4 |          17 |
| 22 | 14921.43 |    1 |         4 |          18 |
| 23 |  3910.50 |    1 |         5 |          19 |
| 24 |   231.37 |    1 |         5 |          20 |
| 25 |  7236.60 |    1 |         5 |          21 |
| 26 |  2226.63 |    2 |         5 |          21 |
| 27 |   500.00 |    2 |         6 |          22 |
+----+----------+------+-----------+-------------+
27 rows in set (0.00 sec)

Нека изтрием акаунт с id=26:

DELETE FROM accounts
WHERE id = 26;

Ако изпълните заявката SELECT отново ще видите, че въпросният ред е изчезнал.

Важно е да се знае, че при използването на FOREIGN KEYS и ON DELETE CASCADE ще бъдат изтрити и записите на редове в таблици, които „сочат“ към записа, който ще бъде изтрит. Например нека видим таблицата „customers“:

mysql> SELECT * FROM customers;
+----+-------------------+---------+----------+
| id | name              | address | bank_mgr |
+----+-------------------+---------+----------+
|  1 | Todor Ivanov      | NULL    |        1 |
|  2 | Petko Stoianov    | NULL    |        1 |
|  3 | Neno Nenov        | NULL    |        2 |
|  4 | Mariana Zaharieva | NULL    |        3 |
|  5 | Elica Zaharieva   | NULL    |        3 |
|  6 | Atanas Petrov     | NULL    |        4 |
|  7 | Ivan Ivanov       | NULL    |        4 |
|  8 | Zlatomir Petrov   | NULL    |        4 |
|  9 | Mihail Ivchev     | NULL    |        5 |
| 10 | Todor Shtilianov  | NULL    |        6 |
| 11 | Ivailo Ivanov     | NULL    |        7 |
| 12 | George Lucas      | NULL    |        8 |
| 13 | George Harison    | NULL    |        8 |
| 14 | Michael Jackson   | NULL    |        8 |
| 15 | Tony Martin       | NULL    |        8 |
| 16 | Tony McCarter     | NULL    |       10 |
| 17 | Alexander Smith   | NULL    |       11 |
| 18 | Maria Smith       | NULL    |       11 |
| 19 | Alain Delrick     | NULL    |       12 |
| 20 | Devry Henry       | NULL    |       12 |
| 21 | Lenard Renne      | NULL    |       12 |
| 22 | Fontaine Rupert   | NULL    |       13 |
+----+-------------------+---------+----------+

Нека изтрием клиент с id 10:

DELETE FROM customers
WHERE id = 10;

Ще видите, че в редовете в таблица „accounts“, чието поле „customer_id“ е било равно на 10, също са изтрити:

mysql> SELECT * FROM accounts;
+----+----------+------+-----------+-------------+
| id | amount   | type | branch_id | customer_id |
+----+----------+------+-----------+-------------+
|  1 |   156.38 |    2 |         1 |           1 |
|  2 |   136.22 |    1 |         1 |           2 |
|  3 |    42.98 |    1 |         1 |           3 |
|  4 |  1236.33 |    1 |         1 |           4 |
|  5 |   211.98 |    2 |         1 |           5 |
|  6 |  1200.00 |    2 |         2 |           6 |
|  7 |   133.48 |    1 |         2 |           7 |
|  8 |   256.41 |    2 |         2 |           8 |
|  9 |  1331.50 |    2 |         2 |           9 |
| 12 |    99.18 |    1 |         2 |          11 |
| 13 |  6712.52 |    1 |         3 |          12 |
| 14 | 12000.56 |    1 |         3 |          12 |
| 15 |   322.99 |    2 |         3 |          12 |
| 16 |   991.63 |    1 |         3 |          13 |
| 17 |   559.32 |    2 |         3 |          14 |
| 18 |   680.13 |    1 |         3 |          15 |
| 19 |   532.57 |    1 |         3 |          15 |
| 20 |   402.26 |    1 |         3 |          16 |
| 21 |  1536.91 |    2 |         4 |          17 |
| 22 | 14921.43 |    1 |         4 |          18 |
| 23 |  3910.50 |    1 |         5 |          19 |
| 24 |   231.37 |    1 |         5 |          20 |
| 25 |  7236.60 |    1 |         5 |          21 |
| 27 |   500.00 |    2 |         6 |          22 |
+----+----------+------+-----------+-------------+
24 rows in set (0.00 sec)

Виждате, че акаунти с id 10 и 11 са изтрити.

Това може да доведе до някои „неудобства“. Нека например се опитаме да изтрием служител с id = 2:

mysql> DELETE FROM employees
    -> WHERE id = 2;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constrai
nt fails (`banks`.`customers`, CONSTRAINT `customers_ibfk_1` FOREIGN KEY (`bank_
mgr`) REFERENCES `employees` (`id`))

Проблемът тук е, че в таблицата „customers“ има FOREIGN KEY „bank_mgr“, който сочи към таблицата „employees“, но НЯМА ON DELETE CASCADE. Това всъщност е съвсем нормално, защото ако уволним даден служител не би следвало да прекратяваме договорите с клиентите на банката, които той обслужва. Как тогава все пак да изтрием служител с id = 2?

Отговорът е, че трябва да направим NULL или да променим към друг bank_mgr всички клиенти, които сочат към bank_mgr=2:

UPDATE customers
SET bank_mgr = NULL
WHERE bank_mgr = 2;

Вече можем да изтрием служител с id = 2:

mysql> DELETE FROM employees
    -> WHERE id = 2;
Query OK, 1 row affected (0.08 sec)

Въпреки, че първоначалното впечатление е, че FOREIGN KEYS ни „пречат“ с тази си особеност, това всъщност ни помага значително, защото така се грижим да правилен интегритет на базата от данни. Не би трябвало в нашата база от данни да има неверни данни, нали?

Тук отново трябва да се обърне изключително внимание на дизайна на базата от данни. Хубаво е в ER диаграмата да си отбелязвате изрично коя връзка има ON DELETE CASCADE и коя не. Винаги преди изпълнение на DELETE трябва да прецените засегнатите връзки и ако има такава без ON DELETE CASCADE, то трябва първо да изпълните заявка от тип UPDATE.

В заключение ще кажем, че е възможно да си спестим този труд, като направим външния ключ с опция „ON DELETE SET NULL“. Това всъщност ще свърши абсолютно същата работа, която демонстрирахме по-горе със заявката UPDATE (то естествено беше с обучителна цел). Препоръчително е да се възползвате от тези удобства.

Задача: Изтрийте банка с code = 2

Упътване: В случая не трябва просто да нулирате записите на външния ключ на customers, а трябва и да изтриете редовете. Предполага се, че когато банка бъде изтрита ще бъдат изтрити и нейните клиенти.

UPDATE <име на таблица>
SET <правило за обновяване>
WHERE <условие>;

От примера с базата данни „banks“ можем да направим следните задачи:

1. Добавя по 2% лихва на всички акаунти от тип 1:

UPDATE accounts
SET amount = amount + amount*2/100
WHERE type = 1;

2. Дава по 20 лева бонус на клиентите с име ‘Ivan Ivanov’:

UPDATE accounts
SET amount = amount + 20
WHERE customer_id IN(
   SELECT id
   FROM customers
   WHERE name = 'Ivan Ivanov'
);

3. Дава по 10 лева бонус на всички клиенти, чийто мениджър на акаунт е ‘John Smith’:

UPDATE accounts
SET amount = amount + 10
WHERE customer_id IN(
   SELECT id
   FROM customers
   WHERE bank_mgr = (
      SELECT id
      FROM employees
      WHERE name = 'John Smith'
   )
);

4. Променя адреса на клона на банка Societe General в град Paris:

UPDATE branches
SET address = '17 cours Valmy'
WHERE name = 'Paris' AND bank_code = (
   SELECT code
   FROM banks
   WHERE name = 'Societe General'
);

5. Можем да обновяваме информация и от две таблици. Следната заявка ще даде два лева на клиент с id 2, като същевременно ще въведе и неговия адрес:

UPDATE customers JOIN accounts
   ON customers.id = accounts.customer_id
SET accounts.amount = accounts.amount + 2, address = 'Opalchenska 12'
WHERE customers.id = 2;

Ясно е, че при по-свободни таблици имаме и гъвкави възможности чрез използването на LEFT и RIGHT JOIN.