PHP5_nachinayushim
.pdf
374 Глава 9
Как база данных сохраняет информацию? Это в некоторой степени зависит от ис+ пользуемой системы управления базами данных, хотя в конечном итоге данные хранят+ ся в виде потоков битов и байтов во множестве файлов ++++++ именно файлов. В действи+ тельности избавиться от файлов не удастся. Однако хорошие базы данных обладают средствами, которые позволяют использовать эти файлы как можно более эффективно.
Базы данных
Что же означает понятие база данных? Строго говоря, база данных представляет собой эффективно организованную совокупность данных, точно так же как библио+ тека представляет собой не более чем упорядоченную совокупность книг. Однако ко+ гда речь заходит о библиотеке, мы чаще всего подразумеваем учреждение в целом ++++++
не только книги, но и персонал, практику работы, а также здание. То же можно ска+ зать и о базах данных, которая представляет собой совокупность: систему управления базами данных и сами данные.
Это не удивительно, потому что в обычных условиях контакт с ‘‘сырыми’’ данными осуществляется только через СУБД или, говоря менее формальным языком, через ба+ зу данных. В большинстве случаев пользователь не видит ‘‘связи’’ этих понятий, по+ этому реальных практических различий не существует. Далее в главе обсуждаются те+ мы установки базы данных, подключения и обращения к ней и т.д., при этом понятие ‘‘база данных’’ используется в его наиболее употребительном, обобщающем смысле.
Архитектурыбаз данных
Прежде всего необходимо определиться с используемой базой данных и типом ее архитектуры. Существует два основных варианта: архитектура встроенных баз дан+ ных и клиент/серверная архитектура. Ниже вкратце рассматриваются оба типа.
Встроенные базы данных
Встроенная база данных работает и хранит данные на той же машине, что и про+ грамма, которая использует эти данные (в данном случае PHP). Такая база данных не+ доступна в сети и в определенный момент времени к ней может подключиться только одна программа. Кроме того, база данных не может совместно использоваться не+ сколькими машинами, потому что каждая из них в конечном итоге сохраняет и ис+ пользует свою собственную отдельную версию данных. Продолжая аналогию с биб+ лиотеками, можно сказать, что такая база данных подобна персональной библиотеке, к которой пользователь имеет исключительный доступ. Часто в мелких приложениях использовать встроенные базы данных более предпочтительно. В более крупных сис+ темах чашу весов перевешивают большие реляционные системы управления базами данных (СУРБД) и поэтому большинство коммерческих предприятий используют клиент/серверные архитектуры баз данных.
В число давно существующих, популярных примеров встроенных баз данных включаются dBase и DBM. PHP предоставляет связь с обеими системами. Недавно в этот перечень добавилась база данных SQLite, которая доступна не только как рас+ ширение для PHP, а фактически встроена в дистрибутив PHP5. SQLite стоит изучить хотя бы только по этой причине. А впечатляющая статистика по производительности определенно подтверждает статус этой системы как перспективной технологии баз данных в PHP. Более подробная информация об SQLite представлена в приложении В, ‘‘Использование SQLite’’.
Введение в базы данных и SQL 375
Клиент/серверные базы данных
Клиент/серверные базы данных предназначены для использования через сеть и позволяют множеству пользователей (которые могут находиться в разных уголках планеты) работать одновременно с одними и теми же данными. Сама база данных (или СУБД) работает как сервер в режиме, очень похожем на режим работы Web+ сервера, который обсуждался в первых главах книги. В принципе, такая база данных способна обрабатывать запросы, поступающие через сетевое соединение из любой точки мира и от любой подходящей клиентской программы. Вместе с тем, нет при+ чин, препятствующих запуску сервера и клиентской программы на одной машине.
Клиент/серверные базы данных близки к метафоре публичной библиотеки. Пуб+ личная библиотека открыта для всех, кто имеет членский билет (т.е. зарегистрирован в библиотеке), а множество работающих в ней библиотекарей могут одновременно обслуживать запросы от большого количества посетителей. Посетители могут прийти лично или позвонить в библиотеку по телефону.
Фактическая работа по поиску и возвращению книг на полки может быть делеги+ рована помощнику, и посетители могут об этом не беспокоиться. Каждый библиоте+ карь, принимающий посетителей, может обслуживать несколько посетителей одно+ временно, но если он хорошо выполняет свою работу, то, вероятно, уделяет каждому читателю достаточно времени, и все посетители довольны таким обслуживанием. Анало+ гично, когда несколько пользователей одновременно получают доступ к клиент/сервер+ ной базе данных, сервер баз данных периодически переключается между ними, создавая у каждого иллюзию одновременного обслуживания всех пользователей.
Описанный выше вид баз данных наиболее распространен в крупных компаниях, где большое количество данных должно использоваться совместно многими сотруд+ никами, где доступ может осуществляться из любой точки сети и где наличие центра+ лизованного хранилища данных значительно упрощает такие важные задачи, как ад+ министрирование и резервное копирование информации. Любые приложения, которые нуждаются в доступе к базам данных, используют специализированные, лег+ ковесные клиентские программы для сообщения с сервером.
Установка и администрирование некоторых СУРБД (систем управления реляци+ онными базами данных) часто оказывается очень дорогим и сложным мероприятием. Общепризнанными представителями этого типа баз данных являются Oracle, DB/2 (производства IBM) и SQL Server (Microsoft) ++++++ массивные, многофункциональные системы, способные хранить и обрабатывать практически любые данные, которые могут понадобиться на современном предприятии. Оборотная сторона этой меда+ ли ++++++ тяжеловесность и дороговизна таких систем, к тому же они могут содержать больше функций, чем от них требуется.
К счастью, существуют альтернативы, такие как системы PostGreSQL и MySQL, каждая из которых представляет собой клиент/серверную систему баз данных с от+ крытым исходным кодом и вот уже много лет является весьма популярной среди PHP+ разработчиков. Эти системы быстры, стабильны и легко удовлетворяют потребности большинства мелких и средних проектов, и, что не менее важно, они бесплатны.
Выбор базы данных
В принципе, в PHP+приложениях можно использовать любую из этих систем. Можно даже привязать одно приложение к нескольким различным системам баз дан+ ных. Чтобы сохранить разумные размеры этой и двух последующих глав, авторы ре+ шили сосредоточиться на одной СУБД ++++++ MySQL.
376 Глава 9
По сравнению с другими данная система предоставляет ряд преимуществ:
это одна из самых популярных систем управления базами данных, используе+ мых в настоящее время в Web+среде;
она свободно доступна для загрузки из Internet и установки на практически лю+ бой машине;
ее легко установить на многих операционных системах (включая Windows и Unix);
эта система доступна как сравнительно недорогая функция во многих пакетах Web+хостинговых услуг;
она проста в использовании и включает в себя несколько удобных инструмен+ тов администрирования;
это быстрая, мощная клиент/серверная система, которая справляется с очень крупными, сложными базами данных и хорошо проявляет себя, когда дело ка+ сается крупных проектов.
Если последний критерий не является определяющим для какого+либо разрабаты+ ваемого приложения (и если нести дополнительные затраты, связанные с функцио+ нальностью баз данных на Web+сервере, нежелательно), то можно с успехом исполь+ зовать встраиваемую базу данных, такую как SQLite.
MySQL ****** свободно доступная СУРБД, разработчики которой лишь недавно присоединились к сообществу открытого исходного кода, выпустив MySQL под лицензией GPL (GNU Public License ****** общедоступная лицензия GNU). Даже до того как она стала бесплатной, для некоммерческого ее использования или использования не на Windows*платформах (Windows*версия MySQL была условно бесплатной) не требовалось покупать лицензию. Уже одно только то, что за использование MySQL теперь не нужно платить деньги, делает эту систему серьезным кандидатом для разработки приложений с базами данных. Если лицензия GPL по какой*либо причине не устраивает разработчика или MySQL требуется внедрить в коммерческое приложение, то все*таки придется приобрести коммерческую лицензионную версию у разработчиков продукта на сайте www.mysql.com.
Здесь и в последующих главах вводится много новых понятий, которые выходят за рамки одной определенной системы управления базами данных, поэтому для начала остановимся на MySQL.
Установка MySQL
В качестве примеров баз данных в книге используются базы данных MySQL, по+ этому читателю следует научиться устанавливать и запускать эту систему.
К моменту написания книги была доступна стабильная версия MySQL 4.0, а фай+ лы (как исходные коды так и скомпилированные бинарные файлы для различных платформ) были доступны на сайте MySQL по адресу www.mysql.com/downloads/ mysql-4.0.html.
Подробности инсталляции (например, последовательность установки и местопо+ ложение ключевых файлов) могут значительно отличаться в зависимости от таких факторов, как используемая операционная система и тип загруженного пакета MySQL (исходный код или скомпилированные бинарные файлы), поэтому рассмотрим не+ сколько вариантов процесса установки.
Введение в базы данных и SQL 377
Установка на Windows
Бинарный установочный пакет для Windows поставляется в виде zip+архива (например, mysql-4.0.16-win.zip), содержащего множество файлов, включая ис+ полняемый файл setup.exe. Для установки MySQL необходимо запустить этот файл, после чего мастер инсталляции предложит несколько параметров установки. Эти па+ раметры определяют, какие файлы будут установлены и где они будут храниться впо+ следствии. Конфигурация по умолчанию (установка в каталог C:\MySQL) должна удовлетворить многих пользователей.
Все основные программы MySQL хранятся в каталоге bin инсталляционного паке+ та. Если при установке были сохранены значения по умолчанию, то путь к файлам этих программ будет C:\mysql\bin. Большинство данных программ (например, mysql.exe, mysqladmin.exe и mysqld.exe) являются инструментами командной строки, поэтому их не следует запускать посредством двойного щелчка мышью на пиктограмме. Их можно будет увидеть в действии позднее.
Программа с информативным названием winmysqladmin.exe, которая поставляет+ ся в стандартной Windows+версии MySQL, предоставляет удобный интерфейс для управ+ ления MySQL+сервером. Эта программа имеет графический пользовательский интерфейс, поэтому ее можно запускать как любую другую программу двойным щелчком мыши.
При первом запуске программа потребует ввести имя пользователя и пароль и соз+ даст учетную запись пользователя для работы со средством администрирования баз данных. После этого запускается программа MySQL+сервера, которая в случае пра+ вильной установки должна запуститься впервые.
После запуска сервера программа winmysqladmin сворачивается в пиктограмму с изображением светофора в панели задач (обычно в правом нижнем углу экрана). Зе+ леный огонек показывает, что сервер запущен, а красный ++++++ что сервер остановлен.
Щелчок правой кнопкой мыши на пиктограмме вызывает контекстное меню, по+ зволяющее запустить или остановить сервер, а также вывести окно winmysqladmin (рис. 9.1), в котором можно просматривать и редактировать различные параметры сервера.
Установка MySQL на Linux
Пользователи Linux могут установить MySQL из бинарного пакета или из исходно+ го кода. В случае использования RPM+пакета необходимо убедиться, что на машине имеются инсталляционные пакеты сервера, клиента, подключаемые файлы и библио+ теки, а также клиентские общие библиотеки для используемой платформы. Должны присутствовать следующие четыре файла (хотя точные имена могут отличаться в за+ висимости от версии MySQL и используемой операционной системы):
MySQL-4.0.16.i386.rpm
MySQL-client-4.0.16.i386.rpm
MySQL-devel-4.0.16.i386.rpm
MySQL-shared-4.0.16.i386.rpm
В случае использования исходного кода понадобится только один архив, mysql- 4.0.18.tar.gz.
378 Глава 9
Рис. 9.1.
Установка MySQL из RPM-пакетов
RPM+пакеты устанавливаются с помощью следующей команды:
> rpm -Uvh filename.rpm
Пакеты необходимо устанавливать в том же порядке, в котором они перечислены в предыдущем разделе.
При установке первого пакета, содержащего MySQL+сервер, на экране появится следующий текст:
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! This is done with:
/usr/bin/mysqladmin -u root password 'new-password' See the manual for more instructions.
Please report any problems with the /usr/bin/mysqlbug script!
The latest information about MySQL is available on the web at http://www. mysql.com
Support MySQL by buying support/licenses at http://www.tcx.se/license.htm. Starting mysqld daemon with databases from /var/lib/mysql
ПОЖАЛУЙСТА, НЕ ЗАБУДЬТЕ УСТАНОВИТЬ ПАРОЛЬ ДЛЯ MySQL-ПОЛЬЗОВАТЕЛЯ root! Это делается с помощью команды:
/usr/bin/mysqladmin -u root password 'новый-пароль'
Дальнейшие инструкции см. в документации.
Пожалуйста, создавайте отчеты о проблемах с помощью сценария
/usr/bin/mysqlbug
Последняя информация о MySQL доступна на Web-сайте
http://www.mysql.com
Чтобы получить техническую поддержку, необходимо приобрести лицензию
Введение в базы данных и SQL 379
http://www.tcx.se/license.htm.
Запускайте mysqld-демон с базами данных из каталога /var/lib/mysql
Программа mysqladmin является одним из клиентских инструментов, поэтому необ+ ходимо повременить с установкой пароля до инсталляции клиентского пакета, кото+ рая описана в этой главе далее. RPM немедленно запускает программу MySQL+сервера mysqld (MySQL+демон). Кроме того, создается сценарий запуска и останова /etc/ rc.d/init.d/mysql, который гарантирует, что MySQL+сервер будет запускаться каж+ дый раз при загрузке и останавливаться при выключении компьютера. Следующий сце+ нарий можно использовать для запуска и останова mysqld:
>/etc/init.d/mysql start
>/etc/init.d/mysql stop
Теперь следует установить пакеты MySQL+client, MySQL+devel и MySQL+shared, по+ сле чего можно переходить к разделу ‘‘Конфигурирование MySQL’’ данной главы.
Установка MySQL из исходного кода
Устанавливать MySQL из исходного кода довольно просто. Для этого необходимо загрузить архив с Web+сайта MySQL и начать процесс инсталляции:
>tar -zxvf mysql-4.0.18.tar.gz
>cd mysql-4.0.18
>./configure --prefix=/usr
>make
Если программа make аварийно завершается, то, скорее всего, это происходит из+ за недостатка памяти. Такое возможно даже на довольно мощных машинах. В этой си+ туации можно сделать следующее:
>rm -f config.cache
>make clean
>./configure --prefix=/usr --with-low-memory
>make
Если и это не помогает, обратитесь к документу www.mysql.com/doc/en/ Compilation_problems.html.
Предположим, что сценарии configure и make выполнились без сбоев, тогда для завершения инсталляции достаточно ввести следующие команды:
>make install
>mysql_install_db
Вдальнейшем для запуска и останова MySQL+сервера, mysqld понадобятся специ+ альные сценарии. Ниже приводится пример сценария для запуска:
#!/bin/bash /usr/bin/mysqld_safe &
и соответственно для останова:
#!/bin/bash
kill 'cat /usr/var/$HOSTNAME.pid'
Эти сценарии имеются в пакете исходных кодов, который можно загрузить с Web+ страницы данной книги (www.wrox.com). Тем, кто предпочитает писать сценарии запуска и останова самостоятельно, рекомендуется создать в текстовом редакторе со+ ответствующие файлы, а затем с помощью команды chmod присвоить им права на вы+ полнение. Например, если сценарий был сохранен как startmysqld, то следует вве+ сти такую команду:
> chmod ugo+rx startmysqld
380 Глава 9
Конфигурирование MySQL
Установив и запустив на локальной тестовой машине сервер баз данных MySQL, следует уделить время конфигурированию системы.
Для конфигурирования MySQL, как и в случае большинства сетевых систем (включая другие клиент+серверные базы данных, операционной системы и т.д.), не+ обходимо войти в систему с определенной учетной записью. Такая мера предосто+ рожности ограничивает доступ к данным путем назначения специфических прав дос+ тупа для каждой учетной записи. Например, один пользователь может иметь право только на просмотр существующих данных, тогда как другому разрешено добавлять новые данные и даже, возможно, изменять привилегии других пользователей.
Главному пользователю в системе, который автоматически получает права на про+ смотр и изменение всех данных и настроек, обычно назначается имя root. Во время ус+ тановки MySQL учетная запись root создается автоматически, однако пароль для нее не устанавливается. Сразу после установки система доступна для использования (в том числе злонамеренного) любым пользователем, имеющим MySQL+клиент и сетевое подключение к данному серверу.
Чтобы обезопасить систему, необходимо из командной строки настроить учетную запись root, выполнив описанные ниже действия.
1.Вызвать окно командной строки и перейти в каталог, содержащий программ+ ные файлы MySQL (обычно C:\mysql\bin\ в Windows или /usr/bin/ в Linux).
2.Ввести следующую команду, подставив желаемый пароль вместо слова elephant:
> mysqladmin -uroot password elephant
После этого можно попытаться вводить в командной строке некоторые другие ко+ манды. Например, команда mysqlshow выводит перечень баз данных, доступных на сервере в текущий момент времени:
> mysqlshow |
|
+----------- |
+ |
| Databases | |
|
+----------- |
+ |
| mysql |
| |
| test |
| |
+----------- |
+ |
Сразу после установки MySQL эта команда показывает, что сервер уже создал две собственных базы данных. Первая mysql ++++++ база данных, в которой хранится вся ин+ формация, необходимая для аутентификации пользователей. Вторая ++++++ пустая тесто+ вая база данных. Команда mysqlshow также может показать содержимое той или иной базы данных при условии ввода правильного пароля:
> mysqlshow -uroot -p mysql Enter password: ********
Database: mysql |
|
|
+--------------- |
|
+ |
| |
Tables |
| |
+--------------- |
|
+ |
| columns_priv |
| |
|
| db |
|
| |
| func |
| |
|
| host |
| |
|
| tables_priv |
| |
|
| user |
| |
|
+--------------- |
|
+ |
Введение в базы данных и SQL 381
В этом случае команда показывает содержимое базы данных mysql ++++++ все систем+ ные данные организованы в виде шести именованных таблиц. В примере наглядно демонстрируется модель хранения данных, которая используется в MySQL для орга+ низации данных. Прежде чем двигаться далее, вкратце рассмотрим некоторые теоре+ тические вопросы и попробуем разобраться, как такие группы таблиц позволяют эф+ фективно хранить данные.
Реляционные базы данных
Рассмотрим еще одну ключевую особенность баз данных ++++++ способ организации информации, с которой работают пользователи. Используя базу данных для получе+ ния модификации или добавления новых данных, необходимо знать, как запрашивать данные. Более того, когда приходится самостоятельно разрабатывать базу данных, необходимо сообщить системе, какие данные и где будут в ней находиться, а также как они будут логически связаны друг с другом.
Большинство баз данных используют так называемую реляционную модель дан+ ных, поэтому они называются реляционными базами данных (или системами управления реляционными базами данных ++++++ СУРБД). В таких базах данные организованы в таб+ лицах, каждая из которых разделяется на строки и столбцы.
В терминах баз данных каждая строка в таблице (кроме заголовка) представляет запись данных: набор внутренне связанных блоков данных. Аналогично, каждый стол+ бец представляет поле: определенный тип данных, который имеет одну и ту же значи+ мость для каждой записи в таблице.
С практической точки зрения понятие ‘‘строка’’ является синонимом записи, а ‘‘столбец’’ ****** синонимом поля. Это необходимо учитывать при визуализации таблиц.
Предположим, что менеджер команды по регби (вид спорта выбран случайно и никак не влияет на понимание работы баз данных) создает базу данных, чтобы от+ слеживать матчи, в которых участвовала его команда, и просит каждого игрока вво+ дить в базу данных после каждого матча свои данные. После второго круга таблица менеджера выглядит так:
Player_Number |
Name |
Phone_number |
Date_Played |
Nickname |
|
|
|
|
|
42 |
David |
555–1234 |
03/03/04 |
Dodge |
6 |
Nic |
555–3456 |
03/03/04 |
Obi-d |
2 |
David |
555–6543 |
03/03/04 |
Witblitz |
14 |
Mark |
555–1213 |
03/03/04 |
Greeny |
2 |
David |
555–6543 |
02/25/04 |
Witblitz |
25 |
Pads |
555–9101 |
02/25/04 |
Pads |
6 |
Nic |
555–3456 |
02/25/04 |
Obi-d |
7 |
Nic |
555–5678 |
02/25/04 |
Nicrot |
|
|
|
|
|
Вскоре становится ясно, что данная таблица будет сильно разрастаться после каж+ дого сыгранного сезона. Очевидно, что такая структура таблицы неэффективна, по+
382 Глава 9
тому что данные каждого игрока ++++++ номер, имя, телефонный номер и т.д. ++++++ вводятся после каждого матча с его участием.
Подобная избыточность в базах данных нежелательна. Например, предположим, что игрок под номером 6 постоянно пропускает голы, и члены его команды решили дать ему новое прозвище (которое здесь не упоминается). Чтобы обновить таблицу, необходимо модифицировать каждую из записей игрока (т.е. поменять в каждой за+ писи значение поля Nickname).
Вдополнение к этому, вводимые игроком после каждого матча данные потребля+ ют ценное пространство на жестком диске. Избыточность крайне неэффективна, впустую расходуется время и пространство на жестком диске.
Вначале 70+х годов прошлого века математик Э.Ф. Кодд (E.F. Codd) предложил уникальный и эффективный способ решения этой проблемы. Он зафиксировал набор правил, применение которых к данным гарантирует создание правильной структуры базы данных. На самом деле он предложил множество таких правил, здесь представ+ лены некоторые из них. Правила (или требования) можно сгруппировать в так назы+ ваемые нормальные формы (normal forms). Данные, соответствующие этим нормальным формам, в значительной степени обуславливают хорошую конструкцию реляционной базы данных. Рассмотрим теперь суть процесса нормализации.
Нормализация
Нормализация определяется как ‘‘процесс разбиения данных на несколько таблиц с целью минимизации количества повторения одних и тех же данных’’. Нормальные формы представляют собой степени нормализации и регулируются изящным набо+ ром правил, которые описаны далее.
Первая нормальная форма (1NF)
Создавать новую таблицу для каждого нового набора связанных данных.
Исключить повторяющуюся информацию в каждой отдельной таблице.
Уникально идентифицировать каждую запись с помощью первичного ключа.
Например, предыдущую таблицу можно представить в форме 1NF в виде двух таб+ лиц. Первая таблица ++++++ информация об игроках:
Player_Id |
Name |
Phone_number |
Nickname |
|
|
|
|
42 |
David |
555–1234 |
Dodge |
6 |
Nic |
555–3456 |
Obi-d |
14 |
Mark |
555–1213 |
Greeny |
2 |
David |
555–6543 |
Witblitz |
25 |
Pads |
555–9101 |
Pads |
6 |
Nic |
555–3456 |
Obi-d |
7 |
Nic |
555–5678 |
Nicrot |
|
|
|
|
|
|
Введение в базы данных и SQL 383 |
|
|
Вторая таблица ++++++ протокол матчей: |
|
|
|
|
|
|
|
Player_Id |
Date_Played |
|
|
|
|
|
42 |
03/03/04 |
|
|
6 |
03/03/04 |
|
|
2 |
03/03/04 |
|
|
14 |
03/03/04 |
|
|
2 |
25/02/04 |
|
|
25 |
25/02/04 |
|
|
6 |
25/02/04 |
|
|
7 |
25/02/04 |
|
|
|
|
|
|
Обратите внимание, насколько естественно исходная таблица разделяется на две новые таблицы. Это связано с тем, что в исходной таблице хранились данные о двух различных элементах: игроках и матчах. Каждая новая таблица содержит данные только об одном элементе. Разделение элементов по таблицам представляет собой важную часть процесса нормализации.
Теперь можно перейти к следующему этапу приведения базы данных к первой нормальной форме: исключить повторения информации в каждой отдельной табли+ це. В таблице игроков имеется некоторая избыточная информация, которую можно устранить. В этом случае таблица примет следующий вид:
Player_Id |
Name |
Phone_number |
Nickname |
|
|
|
|
42 |
David |
555–1234 |
Dodge |
6 |
Nic |
555–3456 |
Obi-d |
2 |
David |
555—6543 |
Witblitz |
14 |
Mark |
555–1213 |
Greeny |
25 |
Pads |
555–9101 |
Pads |
7 |
Nic |
555–5678 |
Nicrot |
|
|
|
|
Теперь в таблице нет дублирующейся информации, таблица представляет только связанную информацию (информацию об игроках). Что можно сказать по поводу уникального идентификатора? Каждая запись должна иметь (по крайней мере, одно) уникальное поле, иначе говоря, поле, в котором нет повторяющихся значений. Ввиду исключительной природы данного поля каждое значение в нем уникально идентифи+ цирует каждую запись таблицы. Поле, которое используется для идентификации за+ писей, называется первичным ключом (primary key). В каждой таблице допускается толь+ ко один первичный ключ.
Перемещение информации об игроках в одну таблицу, а протокола матчей в другую упрощает процесс модификации персональных данных игроков ****** необходимо изменить только одну запись в таблице игроков.