Skip to content

Глава 1. Общая информация

]]>Печать]]> E-mail
Оглавление
Глава 1. Общая информация
1.1. Об этом руководстве
1.2. Соглашения, используемые в данном руководстве
1.3. О русском переводе руководства
1.3.1. Список терминов, принятых в русском переводе
1.4. Что представляет собой MySQL?
1.4.1. История MySQL
1.4.2. Основные возможности MySQL
1.4.3. Насколько стабильным является MySQL?
1.4.4. Насколько большими могут быть таблицы в MySQL?
1.4.5. Вопросы, связанные с Проблемой-2000
1.5. Что представляет собой компания MySQL AB?
1.5.1. Бизнес-модель и услуги, оказываемые компанией MySQL AB
1.5.1.1. Поддержка
1.5.1.2. Обучение и сертификация
1.5.1.3. Консультации
1.5.1.4. Коммерческие лицензии
1.5.1.5. О нашей программе партнерства
1.5.1.6. О рекламе
1.5.2. Как с нами связаться
1.6. Лицензии и поддержка MySQL
1.6.1. Поддержка, предлагаемая компанией MySQL AB
1.6.2. Авторские права и лицензии на MySQL
1.6.3. Лицензии на ПО MySQL
1.6.3.1. Использование ПО MySQL под коммерческой лицензией
1.6.3.2. Бесплатное использование ПО MySQL по лицензии GPL
1.6.4. Логотипы и торговые марки MySQL AB
1.6.4.1. Оригинальный логотип MySQL
1.6.4.2. Логотипы MySQL, которые могут использоваться без письменного разрешения
1.6.4.3. В каком случае для использования логотипов необходимо письменное разрешение?
1.6.4.4. Партнерские логотипы MySQL AB
1.6.4.5. Использование слова MySQL в текстовых документах и презентациях
1.6.4.6. Использование слова MySQL в названиях компаний и продуктов
1.7. Кратко о MySQL 4.x
1.7.1. Поэтапный выпуск
1.7.2. Можно использовать уже прямо сейчас
1.7.3. Встроенный MySQL
1.7.4. Другие функции, доступные в MySQL 4.0
1.7.5. Функции MySQL 4.x, которые будут добавлены в будущем
1.7.6. MySQL 4.1, следующая ветка в разработке
1.8. Источники информации по MySQL
1.8.1. Списки рассылки MySQL
1.8.1.1. Списки рассылки MySQL
1.8.1.2. Как задавать вопросы и направлять сообщения об ошибках
1.8.1.3. Как отправлять отчеты об ошибках или проблемах
1.8.1.4. Рекомендации по ответам на вопросы, направляемые в список рассылки
1.8.2. Пользователи MySQL на IRC
1.9. Насколько MySQL соответствует стандартам?
1.9.1. Каким стандартам соответствует MySQL ?
1.9.2. Запуск MySQL в режиме ANSI
1.9.3. Расширения MySQL к ANSI SQL92
1.9.4. Отличия MySQL от ANSI SQL92
1.9.4.1. Вложенные SELECTы
1.9.4.2. Оператор SELECT INTO TABLE
1.9.4.3. Транзакции и атомарные операции
1.9.4.4. Хранимые процедуры и триггеры
1.9.4.5. Внешние ключи
1.9.4.6. Представления
1.9.4.7. Символы «--» как начало комментария
1.9.5. Известные ошибки и недостатки проектирования в MySQL
1.9.5.1. Ошибки, известные в 3.23 и исправленные в более поздних версиях MySQL
1.9.5.2. Открытые ошибки / особенности строения MySQL
1.10. MySQL и будущее (что предстоит сделать)
1.10.1. Что планируется реализовать в версии 4.0
1.10.2. Что планируется реализовать в версии 4.1
1.10.3. Что планируется реализовать в версии 5.0
1.10.4. Что должно быть сделано в ближайшем будущем
1.10.5. То, что надо сделать когда-нибудь
1.10.6. То, чего не планируется делать

1.9.4.5. Внешние ключи

Следует учитывать, что в SQL внешние ключи используются не для объединения таблиц, а главным образом для проверки целостности ссылочных данных (ограничения внешних ключей). Если необходимо получить результаты из большого количества таблиц от команды SELECT, следует делать это через объединение таблиц:

SELECT * FROM table1,table2 WHERE table1.id = table2.id;

См. разделы Раздел 6.4.1.1, «Синтаксис оператора JOIN» и See Раздел 3.5.6, «Использование внешних ключей».

В версии сервера MySQL 3.23.44 и выше таблицы InnoDB поддерживают проверку ограничений внешних ключей (see Раздел 7.5, «Таблицы InnoDB»). Для таблиц других типов сервер MySQL производит анализ синтаксиса FOREIGN KEY в командах CREATE TABLE, но без выполнения дальнейших действий.

Синтаксис FOREIGN KEY без ON DELETE ... главным образом применяется для целей документирования. В некоторых ODBC-приложениях его можно использовать для автоматического создания выражений WHERE, но обычно это легко сделать вручную. FOREIGN KEY иногда используется в качестве проверки ограничений, но на практике такая проверка не является необходимой, если строки вносятся в таблицу в правильном порядке.

В сервере MySQL можно обойти проблему отсутствия реализации ON DELETE ... добавлением соответствующей команды DELETE в приложение, когда удаляются записи из таблицы, имеющей внешний ключ. На практике при этом достигается почти такая же скорость (в некоторых случаях еще быстрее), как и при использование внешних ключей, и намного большая переносимость.

В версии сервера MySQL 4.0 можно использовать многотабличное удаление, чтобы удалить строки из многих таблиц одной командой (see Раздел 6.4.6, «Синтаксис оператора DELETE»).

В ближайшем будущем мы расширим реализацию FOREIGN KEY таким образом, что информация будет сохраняться в специальном файле таблицы и ее можно будет извлечь с помощью mysqldump и ODBC. На следующем этапе мы внедрим ограничения внешних ключей для приложений, в которых не так просто обойтись без них.

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

Некоторые преимущества внедрения внешних ключей:

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

  • Использование каскадных обновлений и удалений может упростить код клиента.

  • Должным образом разработанные правила внешних ключей помогают в документировании отношений между таблицами.

Недостатки:

  • Ошибки, которые легко сделать в проектировании отношений ключей, могут вызывать сложные проблемы: например, зацикленные правила или ложные комбинации каскадных удалений.

  • Правильно написанное приложение будет само по себе обеспечивать отсутствие нарушения целостности ссылочных данных перед началом работы запроса. Таким образом, дополнительные проверки на уровне базы данных только понизят производительность для такого приложения.

  • Администраторы баз данных часто создают такую сложную топологию связей, при которой затруднительно, а зачастую и вовсе невозможно получить резервную копию или восстановить единичные таблицы.



Просмотров 7753