Вы - -й посетитель этой странички 

Теперь получим список студентов, имена которых состоят ровно из 5 символов:

Пример 22

В данном примере после запроса, начиная с символа #, записан комментарий.

В примерах 21 и 22 мы продемонстрировали основные возможности оператора LIKE, который применяется для сопоставления строк с образцом. Образец представляет собой строку, в которой могут использоваться два специальных символа: "%" и "_". Символ "%" сопоставляется с любой строкой (возможно, пустой). Символ "_" сопоставляется с одним (ровно одним) символом. Любые другие символы, отличные от специальных, могут быть сопоставлены только со специальными символами и сами с собой. Приведем несколько примеров сопоставления строк.

Пример 23

Часть GROUP BY

Возможность группировки результатов запроса — одна из самых полезных и сложных для понимания. С группировкой непосредственно связаны и агрегирующие функции, хотя, как мы видели выше, в простых случаях их можно использовать и без применения группировки. Рассмотрим примеры.

Пример 24

Поинтересуемся количеством юношей и девушек среди студентов:

Группировка всегда производится по значениям некоторых полей (в данном случае по значению одного поля sex). Результаты запроса делятся на группы, в каждой из которых значения полей, по которым производится группировка,

совпадают, а в любых двух группах они различны. Далее, для каждой группы вычисляются требуемые значения агрегирующих функций. Вообще говоря, использование агрегирующих функций при наличии части GROUP BY не является обязательным. Синтаксис языка SQL этого не требует. Можно, например, выполнить следующий запрос":

Смысла в этом запросе, мягко говоря, немного. При его выполнении данные из таблицы student разбиваются на две группы по значению поля sex. Затем из каждой группы берется строка, которая случайно оказалась в данной группе на первом месте, и из нее извлекается поле name. To есть в та блице-результате мы не получим две группы — юношей и девушек! При использовании предложения GROUP BY таблица-результат всегда содержит столько строк, сколько имеется различных наборов значений столбцов, по которым производится группировка.

В этом примере мы выясним средние баллы юношей и девушек:

Пример 27

Подсчитаем количество пропусков занятии студентами:

Здесь следует рассмотреть достаточно тонкий вопрос, который возникнет, если нам потребуется получить список с указанием количества пропусков занятии для оссх студентов, а не только для тех, кто занятия пропускал. Конечно, результат запроса, приведенного в примере 27, очень нагляден. Но при подготовке отчетов (например, по итогам четверти) часто требуется представлять именно полные списки (разумеется, у тех, кто не пропускал занятия, количество пропусков будет равно 0). Как это сделать? Эту задачу можно решить с использованием специального предложения LEFT JOIN. Мы знаем по опыту, что сразу понять, что такое LEFT JOIN, непросто. И в заданиях к урокам не будут встречаться задачи, требующие использования LEFT JOIN. Но мы все же приводим один пример, чтобы неожиданный вопрос детей не застал вас врасплох. Сначала отложите на время базу данных students, сделайте активной базу test и создайте в ней две простые таблицы:

Пример 28

После выполнения приведенных операторов таблицы заполнены следующим образом:

Теперь сравните результаты трех запросов:

В первом запросе выполняется простое объединение таблиц tl и t2 . Во втором запросе из объединения извлекаются строки, удовлетворяющие условию. И, наконец, третий оператор работает следующим образом: берутся бес строки из таблицы, указанной слева в предложении LEFT JOIN; если в таблице, указанной справа, находятся строки, соответствующие условию предложения ON, то они входят в результат, в противном случае соответствующие ячейки остаются пустыми. Но в таблице-результате всегда присутствуют все строки из левой таблицы. Вернемся к базе данных student и решим нашу задачу.

Обратите внимание на то, что теперь мы считаем количество непустых дат COUNT (absence . date) , которые имеются в группах, соответствующих студентам.

В следующем запросе мы получим исчерпывающую информацию обо всех контрольных мероприятиях.

Предложение HAVING, в котором задается условие, имеет отношение к GROUP BY и не употребляется без последнего. Принципиальное отличие предложений WHERE и HAVING заключается в том, что первое применяется до группировки, а второе — после.

Допустим, нас интересуют студенты, имеющие средний балл выше среднего балла, вычисленного по всей таблице score. Сначала найдем общий средний балл:

Теперь получим требуемый список:

Пример 32

Обратите внимание на то, что нам потребовалось присвоить имя полю результата (AVG (score) AS average). Некоторые СУБД позволяют использовать агрегирующие функции непосредственно в предложении HAVING, но MySQL этого не разрешает. Впрочем, это чисто техническое ограничение.

Предложение ORDER BY — очень простое. Оно предназначено для сортировки результатов запросов по возрастанию (asc, такой режим установлен "по умолчанию") или убыванию (desc). Получим тот же список, что и в примере 32, но отсортированный по именам (по возрастанию).

Пример 33

Мы закончили рассмотрение команды SELECT. Разумеется, мы рассмотрели далеко не все ее возможности, полному описанию этой самой мощной команды SQL вполне можно посвятить толстую книгу. Но ключевые вопросы были нами рассмотрены.

Команда UPDATE применяется для модификации информации в базе данных.

update <имя табл1щы> set <пары вида имя_столби_{1а= значение, разделенные запятыми> [where <условие>]}

Попробуем немного похулиганить. Допишем перед именам всех девушек строчку "Nice girl ".

Пример 34

Не получилось! И очень хорошо, что не получилось. Мы увидели в действии систему защиты, которую сами же и установили (см. § б). Чтобы попробовать в действии команду UPDATE и другие команды, модифицирующие информацию в базе данных, необходимо сначала разрешить (в данном случае самим себе) эти действия. Завершим сеанс работы с mysql и начнем новый, но уже с правами администратора:

Затем выполним следующие команды:

При рассмотрении команды CREATE TABLE мы не рассматривали возможность создания таблиц на основе результатов запроса. Но это очень просто и удобно. В результате выполнения команды CREATE TABLE в базе данных students будет создана таблица studentl, которая будет представлять собой точную копию таблицы student. Далее мы разрешили пользователю student делать с ней (только с этой таблицей) что угодно.

Теперь снова завершим работу с клиентом mysql и начнем новый сеанс под именем student. Попробуем вновь ввести команду UPDATE:

Теперь запрос был выполнен успешно. Посмотрим, что у нас получилось:

Пример 36

Команда DELETE предназначена для удаления строк из таблиц базы данных. Обратите внимание на то, что информация из таблиц удаляется (как и добавляется) строками.

DELETE FROM <имя таблицы> [WHERE <усло6ие>]

DELETE FROM student

Внимание! Команда, приведенная в примере, удалит все строки из таблицы student. К счастью, MySQL не позволит нам этого сделать, поскольку у нас нет соответствующих прав.

При рассмотрении команды UPDATE мы создали таблицу studentl, с которой можем делать все, что угодно, на ее примере и рассмотрим команду DELETE. Допустим, администрация учебного заведения решила отчислить несколько студентов, имеющих наихудшие результаты. Было определено, что будут отчислены все юноши, имеющие средний балл, ниже 36 (девушек жалко). Чтобы затем можно было оценить результаты выполнения команды DELETE, сначала получим средние баллы всех студентов:

Пример 37

Как видим, не повезло Томасу (12), Тедди (28), Бену (14), Питеру (10), Яну (8) и Грегори (23). Ну что же, не повезло, так не повезло:

Пример 38

Чтобы оценить результаты выполнения команды DELETE, можно ввести команду, показанную в примере 37.

Здесь уместно кратко обсудить вопрос о сохранении "правильности" (употребительный термин — "целостности") базы данных. После удаления строк из таблицы student может возникнуть ситуация, когда в связанных таблицах останутся строки, которые соответствовали удаленным. Это и называют нарушением целостности базы данных. В некоторых реляционных СУБД, в которых поддерживается явное описание связей между таблицами, задача обеспечения целостности решается путем так называемого "каскадного удаления". В случае, если СУБД поддерживает каскадное удаление, при удалении записей из таблицы, связанной с другими "один к одному" или "один ко многим" (т.е. при удалении записей из таблицы на стороне "одного"), из связанных таблиц удаляются все строки, соответствующие удаляемым.

Другой метод, используемый для обеспечения целостности данных, называется "каскадным обновлением". Каскадное обновление применяется лишь тогда, когда значения ключевых полей таблицы на стороне "одного" могут задаваться (изменяться) пользователем (например, при использовании модификатора AUTO INCREMENT они не могут изменяться пользователем, а генерируются самой СУБД). Каскадное обновление обеспечивает изменение значений внешних ключей в связанных таблицах при изменении значения первичного ключа на стороне "одного".

Наконец, при обеспечении целостности базы данных запрещается добавлять в связанные таблицы на стороне "многих" записи, которым не находится соответствия в таблицах на стороне "одного".

Как мы уже отмечали, MySQL не поддерживает обеспечения целостности баз данных и игнорирует все относящиеся к ним конструкции SQL.

Команда DROP

Команда DROP предназначена для удаления таблиц из баз данных и самих баз данных.

Синтаксис команды DROP

Пример использования команды DROP

§ 6. Установка MySQL в локальной сети класса. Подготовка и администрирование учебной базы данных

Установка и настройка MySQL в локальной сети

Установка MySQL в локальной сети класса немногим сложнее установки на одном компьютере. Собственно, единственным критичным требованием является наличие самой сети. Кроме того, требуется установить в сети поддержку протокола TCP/IP и задать IP-адреса для всех компьютеров в сети. Этот процесс неоднократно описывался в различных публикациях в "Информатике", здесь же мы лишь напомним, что установка протокола TCP/IP и привязка его к сетевой плате выполняется в "Свойствах" "Сетевого окружения", там же можно присвоить компьютеру IP-Адрес (См. рис. 4, 5)

При подключении к серверу MySQL потребуется вводить IP-адрес компьютера, на котором установлен SQL-сервер. Для того чтобы не вводить каждый раз цифровой адрес, можно прописать адрес SQL-сервера в файле hosts. Напомним (об этом мы тоже неоднократно рассказывали в "Информатике"), что этот файл выполняет роль мини-DNS-cepBepa на локальной машине: посредством него устанавливается соответствие между IP-адресами и именами компьютеров. Устроен файл hosts (он располагается в корне системного каталога Windows) очень просто: в каждой строке указывается IP-адрес некоторого компьютера и его имя (символом "#" отмечается начало комментария). Аля того чтобы на компьютерах-клиентах вместо IP-адреса сервера можно было вводить его имя (например, sqlserver), в файлы hosts надо поместить следующую строчку (разумеется, IP-адрес сервера у вас может быть другим, да и сервер вы можете назвать по-своему): 192.168.0.1 sqlserver

После того как выбрано имя сервера и настроен его адрес, можно задать это имя в конфигурационном файле MySQL my.cnf. Пример конфигурационного файла находится в каталоге C:\mysql (файлту-example.cnf, он помешается туда при установке). Для того чтобы MySQL "увидел" файл конфигурации, его требуется поместить в корневой каталог диска С:.

В конфигурационном файле имеются секции для сервера и клиента. Секция настроек сервера помечена [mysqld], секция настроек клиента помечена [client] (на самом деле мы немного упрощаем ситуацию, но можете быть уверены, что у вас все заработает; если же у вас возникнет необходимость в тонкой настройке MySQL, то впоследствии вы легко справитесь с этим самостоятельно). На клиентских компьютерах файл my. cnf должен содержать только секцию [client] , на сервере в файле my.cnf должны присутствовать обе секции — и [mysqld] , и [client] . Прежде чем привести содержимое конфигурационных файлов для сервера и клиента, следует обратить внимание еще на один важный вопрос. MySQL умеет корректно работать с текстовыми данными в различных кодировках, в частности, и с русскими кодировками КОИ-8 и Windows 1251. Для этого требуется, во-первых, задать в конфигурационном файле кодировку данных, а во-вторых, обеспечить программам доступ к файлам, содержащим кодовые таблицы. Эти файлы располагаются в каталоге C:\mysql\share. Понятно, что сервер до этих файлов и так сможет добраться, а для того чтобы до них добрался клиент, требуется либо поместить их на доступном для чтения сетевом ресурсе, либо просто переписать их на каждый компьютер-клиент. Первый способ является, конечно, предпочтительным.

Итак, опишем конфигурацию компьютера-клиента (мы кратко перечислим здесь ранее описанные действия, чтобы вы ничего не забыли).

Конфигурация компьютера-клиента

1. В файле hosts, который располагается в корне системного каталога Windows, должны быть прописаны IP-адрес и имя компьютера, на котором расположен SQL-сервер. Допустим, компьютер с SQL-сервером называется sqlserver.

2. На компьютер-клиент должен быть переписан единственный файл из каталога С: \mysql\bin на сервере, это файл mysql. ехе. Где вы его расположите, дело ваше, но, наверное, разумно создать каталог mysql и записать этот файл в него.

3. Если вы решите переписать на компьютер-клиент файлы с кодировочными таблицами, то можно просто переписать в каталог mysql весь каталог share, места на диске он почти не занимает.

4. В корень диска С: компьютера-клиента следует записать конфигурационный файл my.cnf со следующим содержимым (комментарии, разумеется, можно убрать):

Комментарием мы отметили строку, которая у вас может выглядеть иначе (например, если вы разместите соответствующий каталог на сетевом ресурсе). Обратите внимание на то, что в конфигурационных файлах символ "\" лучше удваивать. Это не всегда необходимо, но всегда достаточно, чтобы не иметь проблем.

Kонфигурация компьютера-сервера

Конфигурационный файл на сервере может иметь такой вид:

Поясним, почему в конфигурационном файле сервера появилась секция [mysql] . Дело в том, что, помимо программы mysql. exe, на сервере потребуется запускать другие программы-клиенты. Секция [client] относится ко всем программам-клиентам, а секция [mysql] — только Kmysql.exe. На клиентских компьютерах тоже можно было вместо секции [client] использовать секцию [mysql] , поскольку на этих компьютерах имеется всего одна программа-клиент.

И на компьютере-сервере, и на компьютере-клиенте путь к исполняемым файлам MySQL следует добавить в переменную PATH среды.

Для того чтобы проверить, правильно ли все настроено, следует запустить SQL-сервер и попробовать подключиться к нему с клиентского компьютера. Если все настроено правильно, то вы увидите на экране компьютера-клиента знакомое приглашение:

Введя команду status, можно проверить основные параметры конфигурации:

В качестве учебной базы данных мы предлагаем использовать несложную базу данных "Учет успеваемости", которую предлагают разработчики MySQL для демонстрационных целей. (Точнее, эта база данных предлагается автором книги [1] , но поскольку и автор, и редактор этой книги входят в команду разработчиков, то, как говорится, по транзитивности.) База данных "Учет успеваемости" очень похожа на ту, которую мы рассматривали в § 4, хотя у нее есть и некоторые отличия. Эту базу данных можно получить с сервера http://www.kitebird.com/ mysql-book/. Дистрибутив находится в одном файле samp_db .zip. Этот файл следует распаковать во временный каталог. На самом деле в поставку входит несколько баз данных, но нам понадобится только одна. Чтобы не путаться во множестве файлов, создайте каталог для хранения файлов, относящихся к учебной базе данных (назовите его, например, students), и скопируйте в него из временного каталога следующие файлы:

База данных "Учет успеваемости" содержит четыре таблицы: student, score, event и absence. Опишем структуру и приведем несколько первых строк каждой таблицы (названия ключевых полей выделены жирным шрифтом). Кроме того, мы приведем и прокомментируем соответствующие команды CREATE TABLE.

Таблица student предназначена для хранения списка студентов. Для каждого студента хранятся его имя (name) и пол (sex). Кроме того, каждый студент имеет уникальный идентификатор student_id.

Структура этой таблицы создается посредством следующей команды:

Поле sex объявлено перечислимым (enum), принимающим одно из двух значений: 'F' или 'м' — female (женский) или male (мужской).

Ключевое поле (PRIMARY key) student_id объявлено с параметром AUTO_INCREMENT. Благодаря этому мы можем не заботиться об обеспечении уникальности значений в этом поле. При добавлении нового студента ему автоматически будет присвоен уникальный идентификатор (на единицу больший максимального значения в этом столбце). Следует отметить, что на практике чаще всего приходится вручную присваивать идентификаторы и самостоятельно следить за их уникальностью (например, если идентификаторы присваиваются студентам администрацией учебного заведения).

В таблице event хранятся даты (date) и типы (type) контрольных мероприятий. В учебном заведении, для которого проектировалась эта база данных, проводятся контрольные мероприятия двух типов: тесты и викторины. В таблице event тесты (test} обозначаются буквой 'Т' , викторины (quiz) — буквой 'Q' . Каждое мероприятие имеет уникальный идентификатор event_id. Обратите внимание на то, что поле date не могло быть объявлено ключевым, поскольку мыслимой является ситуация, когда в один день проводится несколько контрольных мероприятий. Поскольку в таблице event содержится небольшое количество данных, мы приведем ее полностью.

Структура таблицы event создается посредством следующей команды CREATE TABLE: CREATE TABLE event

В таблице score хранятся баллы (score), полученные студентами (студент определяется полем student_id) на контрольных мероприятих (мероприятие определяется полем event_id). (Система оценок на контрольных мероприятиях — стобалльная.) Важная и интересная особенность таблицы score заключается в том, что она имеет составной ключ — пару полей (student_id, event_id). Действительно, и в поле student_id, и в поле event_id могут содержаться повторяющиеся значения (ведь один студент может иметь оценки за несколько контрольных мероприятий, а за одно контрольное мероприятие могут иметь оценки несколько студентов). Но комбинация полей (student_id, event_id) должна быть уникальной: каждый студент может иметь только одну оценку за данное контрольное мероприятие.

Таблица score создается посредством следующей команды CREATE TABLE (в частности, обратите внимание на формат определения составного ключа):

Таблица absence предназначена для фиксации дней (дат) отсутствия студентов в учебном заведении. Отметим, что создатели базы данных посчитали, что если уж студент пропускает занятия, то в течение целого дня. На наш взгляд, это не самое удачное решение. Разумнее было бы отмечать пропуски контрольных мероприятий, а не целых дней (в § 4 была рассмотрена база данных, где фиксировались именно пропуски занятий). Но, что сделано, то сделано.

Поскольку данных в таблице absence не много (удивительно!), приведем ее целиком:

Как и таблица score, таблица absence имеет составной ключ. Она создается посредством следующей команды:

Связи между таблицами student, event, score и absence показаны на следующем рисунке:

Соответствие строк показано линиями. Для обозначения связи типа "один ко многим" использованы символы "1" (на стороне "одного") и "?" (на стороне "многих"). Те, кто имеет опыт работы в MS Access, возможно, узнали знакомую "Схему данных" и знакомые обозначения. Разумеется, мы не рисовали эту схему вручную, а научили MS Access работать с базой данных MySQL. Это делается совсем просто и часто бывает удобно, но рассмотрение этого вопроса лежит за рамками нашего короткого курса (этот вопрос будет рассмотрен в части 3).

Одним из достоинств MySQL является очень простая и очень надежная система разграничения доступа к данным. Следует отметить, что, поскольку команды управления доступом являются стандартными командами языка SQL, в принципе нет необходимости вникать во внутреннюю кухню системы безопасности MySQL (команды-то одинаковые, но реализация средств разграничения доступа у каждого SQL-сервера своя, поэтому мы и говорим о внутренней кухне именно MySQL). Однако знать то, как все устроено внутри, полезно и для того, чтобы лучше представлять суть, и для того, чтобы увереннее чувствовать себя в сложных ситуациях (среди детей ведь попадаются и постоянные читатели журнала "Xakep", в котором иногда встречаются статьи, посвященные взлому SQL-серверов, см., например, [5] ).

Сначала рассмотрим управление системой безопасности с помощью стандартных средств SQL, а потом посмотрим, как они реализованы в MySQL. На логическом уровне можно представлять себе, что для разграничения доступа к данным SQL-серверы используют следующую табличку:

Но, позвольте, скажете вы, до сих пор мы без проблем подключались к серверу и знать не знали о каких-то именах, паролях, адресах... Вот это-то и ужасно! Для того чтобы начинающие пользователи не испытывали проблем, связанных с системой защиты, непосредственно после установки сервер MySQL никак не защищен. Кто угодно может делать с ним что угодно. И первая задача, которую должен решить учитель при подготовке к урокам, — обеспечить защиту сервера.

После установки MySQL таблица разграничения доступа имеет следующий вид:

Перво-наперво необходимо удалить анонимного пользователя, которому в этой таблице соответствуют пустые ячейки в поле "Имя пользователя". Для этого необходимо подключиться к серверу и выполнить следующие команды (комментарии, разумеется, можно опустить):

После выполнения этих команд таблица разграничения доступа примет вид:

Это уже лучше, но все еще очень плохо, поскольку пользователь root, который может все , подключается к серверу без пароля. Для того чтобы задать пароль пользователю root, введите следующие команды:

После этого завершите текущий сеанс работы в mysql и вновь подключитесь к серверу, задав в командной строке и имя пользователя, и пароль:

Обратите внимание на то, что между ключом -р и паролем нет пробела.

Теперь сервер MySQL защищен, даже слишком защищен, поскольку никто, кроме пользователя root, подключиться к нему не может. Нам необходимо создать учетную запись, которую будут использовать для доступа к серверу дети. Для этого следует вновь подключиться к серверу с правами пользователя root и ввести следующую команду:

Здесь мы разрешили пользователю student (если пользователя, которому что-либо разрешается, не существует, он создается; таким образом, мы еще и создали пользователя student) выполнять команду SELECT над всеми таблицами базы данных students.

Попробуйте подключиться к серверу в качестве пользователя student и получить доступ к базе данных mysql:

Если вы все сделали правильно, то вас не пустят. И детей не пустят, что важнее. А к базе данных students их пустят, но хулиганить не позволят:

Вот пока и все. Теперь таблица разграничения доступа на нашем сервере имеет вид:

В "большой Интернет" с такой таблицей лучше не высовываться (у нас и пользователь root может подключаться откуда угодно и, подключившись откуда угодно, делать что угодно, и пользователь student не имеет пароля). Но для работы в школьной локальной сети она вполне подходит: усложнять себе (и детям) жизнь, устанавливая драконовские ограничения, тоже не следует.

В заключение этого раздела поясним, почему имеются две записи для пользователя root. Вообще говоря, для любого пользователя в таблице разграничения доступа может быть несколько записей. Это бывает нужно вот зачем: одно дело, когда пользователь (в нашем случае администратор) непосредственно работает за клавиатурой компьютера, на котором установлен сервер, и совсем другое дело, если он получает доступ к серверу по сети. Можно предположить, что если уж человек добрался до клавиатуры сервера, то ему действительно "можно все". Но давать такие же права для доступа из сети иногда бывает небезопасно. Поэтому администраторы иногда разрешают себе все при работе с компьютера localhost и сами ограничивают свои права при работе с другого компьютера (например, разрешают только чтение, но не модификацию важных данных). Бывают и более гибкие разграничения: для работы с компьютера localhost; с компьютера, расположенного в собственной локальной сети; с компьютера, расположенного вне локальной сети, и т.д.

В этом разделе мы опишем основы системы безопасности MySQL. Безусловно, приведенная здесь информация не является исчерпывающей, но ее вполне достаточно для того, чтобы самостоятельно разобраться с любой проблемой, если таковая возникнет. Полная информация о системе безопасности содержится в электронной документации.

Ключевую роль в системе безопасности играет база данных с именем mysql. В ней содержится пять таблиц. На основе содержащейся в них информации MySQL при подключении пользователя и выполнении любого запроса решает: можно или нельзя.

Самая важная таблица — user. Подключитесь к серверу с правами администратора. Для того чтобы сохранить протокол работы в файле (например, в файле user.txt), введите команду:

Нас интересует содержимое таблицы user:

Отмените вывод протокола в файл (иначе файл будет заблокирован):

Теперь посмотрим, что хранится в таблице. (Мы вынуждены "разорвать" таблицу, в противном случае она н уместилась бы на странице.)

Как видите, в таблице user хранятся имена пользователей, адреса (или имена) компьютеров, зашифрованные пароли и перечисляются все действия, которые могут выполняться. Эти действия либо разрешены ("Y"), в частности, пользователю root разрешено все, либо запрещены ("N"), в частности, пользователю student все запрещено. Но... Пользователь student ведь кое-что может, ему разрешено выполнять команду SELECT в базе данных students. Вот именно! Не вообще выполнять SELECT, а только в базе данных students. В таблице user определяются глобальные права пользователей. То есть если в ней что-то разрешается, то это разрешение распространяется на все базы данных, все таблицы и все столбцы в них. Для того чтобы разрешения касались только конкретных баз данных, они должны быть заданы в таблице db. Когда пользователь student попробует выполнить команду SELECT, MySQL посмотрит в таблицу user и увидит, что где попало пользователю student выполнять SELECT нельзя. Но это не означает немедленного запрещения. Затем MySQL посмотрит в таблицу db и обнаружит, что "вообще" нельзя, но в базе данных students — можно. Таблицы db, tables_priv и columns_priv устроены аналогично таблице user, поэтому мы не приводим их содержимое. Таблица host используется для весьма тонких настроек, и мы ее не рассматриваем.

Мораль же такова: берегите базу данных mysql и не давайте никому никаких прав для доступа к ней.

1. Дюбуа Поль. MySQL. Москва, Санкт-Петербург, Киев: Издательский дом "Вильяме", 2001.

2. Ливчак А.Б., Гейн А.Г. "Кухня" СУБД Access.'Информатика № 27/2000.

3. Еремин Е.А., Шестаков А.П. Примерные ответы на примерные билеты. Билет № 12. Информатика № 15/2002.

4. Джудит С. Бауман, Сандра А. Эмерсон, Марси Дарновски. Практическое руководство SQL (Третье издание). Москва, Санкт-Петербург, Киев: Издательский дом "Вильяме", 2001.

5. "SQL Hacking". Журнал "Xakcp" № 30.

В начало спецвыпуска