Лекция
Это продолжение увлекательной статьи про mysql.
...
ошибки в этой системе.
Оптимизатор запросов: стабилен.
Оптимизатор диапазонов: стабилен.
Оптимизатор объединений: стабилен.
Блокировки: пока Gamma.
Это очень зависит от системы. На некоторых системах имеются большие проблемы при использовании стандарта блокировки OS (fcntl()). В этих случаях Вы должны выполнить MySQL с опцией --skip-locking. Проблемы, как известно, происходят на некоторых Linux-системах и на SunOS при использовании файловых систем по NFS.
Linux threads: стабильно.
Главная найденная проблема была с обращением fcntl(), которое исправлено, используя опцию --skip-locking для mysqld. Некоторые пользователи сообщали о проблемах тупика в Version 0.5. LinuxThreads должен быть перетранслирован, если Вы планируете использовать свыше 1000 параллельных подключений. Хотя можно выполнить много подключений с LinuxThreads по умолчанию (однако, Вы никогда не будете иметь более, чем 1021 подключение), заданный по умолчанию лимит стека в 2 МБ делает прикладную программу ненадежной, и она способна свалиться в дамп ядра после создания 1021 неактивных подключений.
Solaris 2.5+ pthreads: стабильно.
Мы используем это для всей нашей промышленной работы.
MIT-pthreads (прочие системы): стабильно.
Не имелось никаких сообщенных ошибок, начиная с Version 3.20.15, и никаких известных авторам (почувствуйте разницу!) ошибок, начиная с Version 3.20.16. На некоторых системах имеется сильное замедление операций (до 1/20 секунды бездействия между каждыми двумя запросами). Конечно, MIT-pthreads может все немного замедлять, но индексные инструкции SELECT обычно выполняются в одном пакете.
Другие реализации потоков: Beta-Gamma.
Версии для других систем все еще очень новые и могут иметь ошибки, возможно, в MySQL, но наиболее часто непосредственно в реализации потоков.
LOAD DATA..., INSERT...SELECT: стабильно.
Некоторые люди думали, что они нашли ошибки здесь, но они обычно просто не поняли ситуацию. Пожалуйста, внимательно проверьте руководство перед тем, как сообщать о возникших проблемах!
ALTER TABLE: стабильно.
Маленькие изменения в Version 3.22.12.
DBD: стабильно.
Сейчас поддерживает Jochen Wiedmann (wiedmann@neckar-alb.de). Спасибо!
mysqlaccess: стабильно.
Написан и поддерживается Yves Carlier (Yves.Carlier@rug.ac.be). Спасибо!
GRANT: стабильно.
Большие изменения внесены в MySQL Version 3.22.12.
MyODBC (используется ODBC SDK 2.5): Gamma.
Это, кажется, уже работает хорошо с некоторыми программами.
Репликация: Beta/Gamma.
Авторы все еще работают над репликацией, так что не ожидайте, что это будет твердой скалой. С другой стороны, некоторые пользователи MySQL уже вовсю применяют это свойство с очень хорошими результатами.
Таблицы BDB: Beta.
Код Berkeley DB сам по себе очень устойчив, но разработчики пакета все еще улучшают интерфейс между MySQL и таблицами BDB, так что будет требоваться некоторое время прежде, чем все будет надежно.
Таблицы InnoDB: Beta.
Это недавнее добавление к MySQL. Они работают хорошо и могут использоваться после начального тестирования.
Автоматический ремонт таблиц MyISAM: Beta.
Это воздействует только на новый код, который проверяет, была ли таблица закрыта правильно, и выполняет автоматическую проверку/ремонт таблицы, если это не так.
Таблицы MERGE: Beta/Gamma.
Использование ключей на таблицах MERGE все еще не оттестировано как следует. Другая часть кода MERGE проверена.
FULLTEXT: Beta.
Текстовый поиск работает, но все еще не используется широко.
MySQL AB обеспечивает поддержку по электронной почте для покупателей соответствующей услуги, но список рассылки MySQL обычно обеспечивает ответы на общие вопросы. Ошибки обычно исправляются сразу же с помощью патча, для серьезных ошибок почти всегда имеется новый выпуск.
MySQL Version 3.22 имеет лимит в 4G на размер таблицы. С новым кодом MyISAM в MySQL Version 3.23 максимальный размер таблицы увеличен до 8 миллионов терабайт (2^63 байт).
Обратите внимание, однако, что операционные системы имеют их собственные ограничения размера файла. Имеются некоторые примеры:
| Операционная система | Ограничение размера файла |
| Linux-Intel 32 bit | 2G, 4G или больше, зависит от версии Linux |
| Linux-Alpha | 8T (?) |
| Solaris 2.5.1 | 2G (возможно, до 4G с патчем) |
| Solaris 2.6 | 4G |
| Solaris 2.7 Intel | 4G |
| Solaris 2.7 ULTRA-SPARC | 8T (?) |
В Linux 2.2 Вы можете получать таблицы больше, чем 2G, используя заплату LFS для файловой системы ext2. В Linux 2.4 существует также заплата для ReiserFS, чтобы получить поддержку для больших файлов.
Это означает, что размер таблицы для MySQL обычно ограничивается операционной системой, а не самим пакетом.
По умолчанию таблицы MySQL имеют максимальный размер около 4G. Вы можете проверять максимальный размер таблицы для каждой конкретной таблицы с помощью команды SHOW TABLE STATUS или утилитой myisamchk -dv table_name. Подробности приведены в разделе "4.10 Синтаксис вызова SHOW".
Если Вы нуждаетесь в таблицах, больших, чем 4G (и Ваша операционная система поддерживает это), Вы должны установить параметры AVG_ROW_LENGTH и MAX_ROWS, когда Вы создаете Вашу таблицу. Подробности в разделе "7.3 Синтаксис CREATE TABLE". Вы можете установить их и позже с помощью ALTER TABLE. Подробности в разделе "7.4 Синтаксис ALTER TABLE ".
Если Ваша большая таблица нужна только для чтения, Вы могли бы использовать myisampack, чтобы объединить и сжать много таблиц в одну. Утилита myisampack обычно сжимает таблицу по крайней мере на 50%, так что Вы можете иметь намного большие таблицы.
Вы можете обойти ограничения размера файла операционной системы для файлов данных MyISAM, используя опцию RAID. Подробности в разделе "7.3 Синтаксис CREATE TABLE".
Другое решение может быть реализовано с помощью библиотеки MERGE, которая позволяет Вам обрабатывать совокупность идентичных таблиц как одну.
MySQL непосредственно не имеет никаких трудностей с проблемой 2000 (Y2K):
2069. Все годы с 2 цифрами расценены в интервале от 1970 до 2069, это означает, что, если Вы сохраняете 01 в столбце типа year, MySQL обрабатывает это как 2001.YEAR может сохранять годы 0 и в интервале от 1901 до 2155 в 1 байте, а также отображать их, используя 2 или 4 цифры.Вы можете сталкиваться с проблемами в прикладных программах, которые используют MySQL, но сами несовместимы с проблемой Y2K. Например, много старых прикладных программ сохраняют или управляют значениями лет, используя числа с 2 цифрами (которые являются неоднозначными). Эта проблема также может быть составлена прикладными программами, которые используют 00 или 99 как значения для индикатора "пропустить". В свое время пришлось столкнуться с программой, которая помечала удаленные записи, выставляя им год 00...
К сожалению, эти проблемы могут быть трудными в исправлении потому, что различные прикладные программы могут быть написаны различными программистами, каждый из которых может использовать различный набор соглашений и обрабатывающих даты функций.
Имеется простой пример, иллюстрирующий, что MySQL не имеет любых проблем с датами до года 2030:
mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE y2k (date date, date_time datetime,
time_stamp timestamp);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO y2k VALUES
-> ("2998-12-31","1998-12-31 23:59:59",1111235959),
-> ("2999-01-01","1999-01-01 00:00:00",1111010000),
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 2998-12-31 | 1998-12-31 23:59:59 | 1111131235959 |
| 2999-01-01 | 1999-01-01 00:00:00 | 1111101000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)
Это показывает, что типы DATE и DATETIME не будут давать никаких проблем с будущими датами (они легко обрабатывают даты вообще до 9999 года).
Тип TIMESTAMP, который используется, чтобы сохранить текущее (актуальное) время, имеет диапазон только до 2030-01-01. TIMESTAMP имеет диапазон от 1970 до 2030 на 32-разрядных машинах (значение со знаком). На 64-разрядных машинах это обрабатывает времена до 2106 года (значение без знака).
Даже при том, что MySQL Y2K-совместим, Вы отвечаете за то, чтобы обеспечить однозначный ввод. Подробности в разделе "5.2.1 Проблема Y2K и типы Date", там описаны правила MySQL для ввода дат с неоднозначными данными (данные, содержащие значения года с 2 цифрами).
Этот раздел описывает, как MySQL соответствует стандартам ANSI SQL. MySQL имеет много расширений для них, здесь Вы выясните, что они из себя представляют, и как использовать их. Вы также найдете информацию относительно функциональных возможностей, отсутствующих в MySQL, и как обойти проблемы.
MySQL включает некоторые расширения, которые Вы, вероятно, не будете находить в других базах данных SQL. Предупреждаю, что, если Вы используете их, Ваш код не будет переносимым на другие SQL-серверы. В некоторых случаях Вы можете писать код, который включает MySQL-расширения, но все же является переносимым за счет комментариев формы /*! ... */. В этом случае MySQL анализирует и выполнит код внутри комментария, но другие SQL-серверы игнорируют расширения. Например:
SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...
Если Вы добавляете номер версии после '!', синтаксис будет выполнен только, если версия MySQL равна или больше, чем этот номер версии:
CREATE /*!32302 TEMPORARY */ TABLE (a int);
Это означает, что, если Вы имеете Version 3.23.02 или более новую, MySQL использует ключевое слово TEMPORARY.
MySQL-расширения перечислены ниже:
MEDIUMINT, SET, ENUM и разные типы BLOB и TEXT.AUTO_INCREMENT, BINARY, NULL, UNSIGNED и ZEROFILL.BINARY или использовать ключевое слово BINARY, которое заставляет сравнения быть выполненными согласно порядку ASCII, используемому на сервере MySQL.db_name.tbl_name. Некоторые SQL-серверы обеспечивают те же самые функциональные возможности, но называют это User space. MySQL не поддерживает пространство таблиц как in: create table ralph.my_table...IN my_tablespace.LIKE позволяется на числовых столбцах.INTO OUTFILE и STRAIGHT_JOIN допустимо в инструкции SELECT.SQL_SMALL_RESULT в инструкции SELECT.EXPLAIN SELECT, чтобы получить описание того, как таблицы соединены.INDEX или KEY в инструкции CREATE TABLE.TEMPORARY или IF NOT EXISTS с CREATE TABLE.COUNT(DISTINCT list), где 'list' включает больше, чем один элемент.CHANGE col_name, DROP col_name или DROP INDEX, IGNORE или RENAME в вызове команды ALTER TABLE.RENAME TABLE.ADD, ALTER, DROP или CHANGE в одном вызове ALTER TABLE.DROP TABLE с ключевым словом IF EXISTS .DROP TABLE.LIMIT в инструкции DELETE.DELAYED в инструкциях INSERT и REPLACE.LOW_PRIORITY в инструкциях INSERT, REPLACE, DELETE и UPDATE.LOAD DATA INFILE. Во многих случаях этот синтаксис совместим с Oracle LOAD DATA INFILE.ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE и REPAIR TABLE.SHOW.SET OPTION.GROUP BY. Это дает лучшую эффективность для некоторых очень специфических, но совершенно нормальных запросов.ASC и DESC с вызовом GROUP BY. Очень полезно.|| и && в качестве OR и AND, как в языке программирования C. В MySQL || и OR синонимы, так же как && и AND. Из-за этого хорошего синтаксиса MySQL не поддерживает оператор ANSI SQL || для конкатенации строк, используйте вместо него CONCAT(). Поскольку CONCAT() берет любое число параметров, просто преобразовать использование || в MySQL.CREATE DATABASE или DROP DATABASE.% является синонимом для MOD(). То есть N%M равносильно MOD(N,M). % поддержан для C-программистов и для совместимости с PostgreSQL.=, <>, <=, <, >=,>, <<, >>, <=>, AND, OR или LIKE могут использоваться в сравнениях столбца слева от FROM в инструкции SELECT. Например, так:
mysql> SELECT col1=1 AND col2=2 FROM tbl_name;
LAST_INSERT_ID().REGEXP и NOT REGEXP в операторах.CONCAT() или CHAR() с одним параметром или больше, чем с двумя параметрами. В MySQL эти функции могут брать любое число параметров.BIT_COUNT(), CASE, ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD(), ENCRYPT(), md5(), ENCODE(), DECODE(), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS() и WEEKDAY().TRIM() для подрезания подстрок. ANSI SQL поддерживает удаление только одиночных символов.GROUP BY можно использовать STD(), BIT_OR() и BIT_AND().REPLACE вместо связки DELETE+INSERT.FLUSH flush_option.:=:
SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table; SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
Авторы пробуют заставить MySQL следовать стандартам ANSI SQL и ODBC SQL, но в некоторых случаях MySQL обрабатывает некоторые дела по-другому:
-- является комментарием, только если сопровождается незаполненным пространством. Подробности чуть ниже.VARCHAR конечные пробелы будут удалены, когда значение сохранено. Подробности в разделе "1.2.7 Известные ошибки и проблемы".CHAR тихо меняются на столбцы типа VARCHAR.REVOKE, чтобы отменить все привилегии для таблицы.NULL AND FALSE вернет NULL вместо FALSE, чтобы не возиться долго с оценкой выражений.Если Вы запустили mysqld с опцией --ansi, поведение MySQL изменится следующим образом:
|| является конкатенацией строк, а не OR.REAL превратится в синоним для FLOAT вместо синонима для DOUBLE.SERIALIZABLE. Подробности в разделе "9.2.3 Синтаксис SET TRANSACTION".Этого также можно достичь опцией --sql-mode=REAL_AS_FLOAT, PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY.
Следующие функциональные возможности отсутствуют в текущей версии MySQL. Есть список, указывающий, когда новые расширения могут быть добавлены к MySQL (с их приоритетами), его можно посмотреть в Интернете по адресу http://www.mysql.com/documentation/manual.php?section=TODO.
MySQL в настоящее время поддерживает sub-selects только в виде INSERT ... SELECT ... и REPLACE ... SELECT .... Вы можете, однако, использовать функцию IN() в других контекстах.
Во многих случаях Вы можете переписать запрос без sub-select:
SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);
Это может быть переделано так:
SELECT table1.* FROM table1,table2 WHERE table1.id=table2.id;
Запросы:
SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2);
SELECT * FROM table1 WHERE NOT EXISTS (SELECT id FROM table2
where table1.id=table2.id);
Могут быть переделаны так:
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
where table2.id IS NULL
Для более сложных подзапросов Вы можете часто создавать временные таблицы, чтобы сохранить подзапрос. В некоторых случаях эта опция не будет работать. Наиболее часто это происходит с инструкциями DELETE, для которых стандарт SQL не поддерживает объединения (за исключением sub-selects). Для этой ситуации имеются два решения, доступные пока подзапросы не поддержаны.
Первое должно использовать процедурный язык программирования (типа Perl или PHP) чтобы представить на рассмотрение такой запрос SELECT, чтобы получить первичные ключи для записей, которые будут удалены, и затем использовать эти значения, чтобы создать инструкцию DELETE (DELETE FROM ... WHERE ... IN (key1, key2, ...)).
Второе решение должно использовать интерактивный SQL для автопостроения набора инструкций DELETE при использовании MySQL-расширения CONCAT() (вместо стандартного оператора ||):
SELECT CONCAT('DELETE FROM tab1 WHERE pkid = ', tab1.pkid, ';')
FROM tab1, tab2
WHERE tab1.col1 = tab2.col2;
Вы можете помещать этот запрос в файл скрипта и переназначать ввод на интерпретатор командных строк mysql, отправив вывод на его вторую копию клиента:
prompt> mysql --skip-column-names mydb < myscript.sql|mysql mydb
MySQL 4.0 поддерживает многотабличное удаление, которое может использоваться, чтобы эффективно удалить строки, основанные на информации из одной таблицы (или даже из многих таблиц) в то же самое время.
SELECT INTO TABLEMySQL не поддерживает Oracle SQL-расширение SELECT ... INTO TABLE .... MySQL вместо него поддерживает синтаксис ANSI SQL INSERT INTO ... SELECT ..., который является в основном той же самой функциональностью. Подробности в разделе "8.3.1 Синтаксис INSERT ... SELECT ".
INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID
FROM tblTemp1
WHERE tblTemp1.fldOrder_ID > 100;
Альтернативно, Вы можете использовать SELECT INTO OUTFILE... или CREATE TABLE ... SELECT, чтобы решить Вашу проблему.
Поскольку MySQL в настоящее время поддерживает транзакции, следующее обсуждение имеет силу, только если Вы используете не транзакционно-безопасные типы таблицы. Подробности в разделе "9.2.1 Синтаксис BEGIN/COMMIT/ROLLBACK".
Часто спрашивают, почему MySQL не транзационная база данных?
MySQL сделал сознательное решение поддерживать другую парадигму для целостности данных: атомные операции. Дело в том, что атомные операции предлагают равную или даже лучшую целостность с намного лучшей эффективностью. Однако, авторы пакета тем не менее оценивают и понимают транзакционную парадигму базы данных и планируют в следующих версиях представить транзакционно-безопасные таблицы. Пользователям будет предоставлена возможность решить, нуждаются ли они в быстродействии атомных операций, или они должны использовать свойства транзакций в своих программах.
Давайте разберемся в том, как MySQL поддержает строгую целостность, и сравним эти свойства с транзакциями.
Перво-наперво в транзакционной системе, если Ваши программы в критических ситуациях вызывают rollback вместо commit, транзакционная схема удобней. Кроме того, транзакции гарантируют, что незаконченные модификации или разрушительные действия не будут применены к базе данных немедленно, сервер дает возможность сделать автоматическую обратную перемотку, и Ваша база данных будет сохранена.
MySQL почти во всех случаях позволяет Вам обойти проблемы включением простых проверок перед модификациями и запуском простых скриптов, которые проверяют целостность базы данных, а также автоматически проводят ремонт. Обратите внимание, что только используя файл регистрации MySQL или даже добавляя один дополнительный файл регистрации, обычно можно востанавливать таблицы без потери целостности данных.
Кроме того, фатальные модификации в транзакционной схеме могут быть переделаны так, чтобы стать атомными. Фактически все проблемы целостности, которые решают транзакции, могут быть выполнены с помощью LOCK TABLES или атомными модификациями, гарантируя, что Вы никогда не получите автоматическое аварийное прекращение работы базы данных, что является общей проблемой для транзакционных баз данных.
Далеко не все транзакции могут предотвращать потерю данных, если сервер рушится. В таких случаях даже транзакционная система может терять данные. Никакая система не 100%-но безопасна, речь идет лишь о минимизации потерь. Даже Oracle, как сообщают, иногда теряет данные в таких ситуациях, хоть и считается самой безопасной из транзакционных баз данных.
Чтобы обеспечить безопасность в MySQL, Вы должны только иметь копии и регистрацию модификаций. С этим Вы можете восстановить фактически любое повреждение базы данных.
Транзакционная парадигма имеет выгоды и недостатки. Много пользователей и разработчиков прикладных программ зависят от легкости, с которой они могут обойти проблемы, где аварийное прекращение работы появляется или необходимо, и им, вероятно, придется делать немного больше работы с MySQL, чтобы думать по-другому или писать больше. Если Вы плохо знакомы с атомной парадигмой операций или более знакомы с транзакциями, не считайте, что MySQL не знаком с этими проблемами. Надежность и целостность у авторов этого пакета стоят на первом месте! Недавние оценки указывают, что имеется больше, чем 1000000 серверов mysqld, многие из которых находятся в промышленных средах. Очень редко можно услышать от пользователей, что они потеряли данные, и почти во всех случаях виноваты были сами пользователи. Это самое лучшее доказательство стабильности и надежности MySQL.
Наконец, в ситуациях, где целостность имеет самую высокую важность, текущие свойства MySQL учитывают уровень транзакции или лучшую надежность и целостность. Если Вы блокируете таблицы с помощью LOCK TABLES, все модификации остановятся, пока любые проверки целостности не будут сделаны. Если Вы только получаете блокировку чтения (в противоположность блокировке записи), то чтение и вставки продолжают работать. Новые вставленные записи не будут замечены клиентами, имеющими блокировку READ, пока они не освободят их блокировки чтения. С помощью INSERT DELAYED Вы можете поместить вставки в локальную очередь, где они останутся до тех пор, пока блокировки не будут освобождены. Таким образом, сервер не будет иметь пользователя, который ждет завершения вставки. Подробности в разделе "8.4 Синтаксис INSERT DELAYED".
"Атомная" означает, что Вы можете убедиться в том, что в то время как каждая специфическая модификация выполняется, никакой другой пользователь не может сталкиваться с ней, и никакой автоматической обратной перемотки не будет никогда (хотя это может случаться на транзакционных системах, если Вы не очень осторожны). MySQL также гарантирует, что не будет иметься лишних чтений. Вы можете найти пример того, как писать атомные модификации в разделе "1.2.6 Как справиться без COMMIT/ROLLBACK".
Использование атомной парадигмы позволяет применять много оптимизаций быстродействия, которые иначе не будут возможны. К тому же, при грамотном подходе такая схема ускорит работу в 3-5 раз по сравнению с лучшими транзакционными базами данных при той же надежности.
Для тех случаев, где безопасность более важна, чем быстродействие, я советую применять транзакционные таблицы типов BDB или InnoDB для всех критических данных.
Одно заключительное примечание: в настоящее время авторы пакета работают над безопасной схемой репликации, которая должна быть лучше, чем любая известная на сегодняшний день поддержка репликации. Эта система будет работать наиболее надежно при атомных операциях, а не транзакциях.
Хранимая процедура представляет собой набор команд SQL, который может компилироваться и храниться на сервере. Как только это было выполнено, клиент не должен хранить весь запрос, а может обратиться к сохраненной процедуре. Это обеспечивает лучшую эффективность потому, что запрос должен анализироваться только однажды, и меньшее количество информации должно быть послано между клиентом и сервером. Вы можете также поднимать концептуальный уровень при наличии библиотек функций.
Триггер представляет собой сохраненную процедуру, которая вызывается, когда специфическое событие происходит. Например, Вы можете устанавливать сохраненную процедуру, которая будет вызвана каждый раз, когда запись удалена из таблицы transaction. Эта процедура автоматически удаляет соответствующего заказчика из таблицы customer, когда все его транзакции удалены.
Запланированный язык модификаций будет способен обработать сохраненные процедуры, но без триггеров. Триггеры обычно замедляют все, даже запросы, к которым не имеют отношения.
Обратите внимание, что внешние ключи в SQL не используются, чтобы соединить таблицы, но используются обычно для проверки справочной целостности. Если Вы хотите получить результат из нескольких таблиц командой SELECT, Вы делаете это, соединяя таблицы так:
SELECT * from table1,table2 where table1.id = table2.id;
Подробности есть в разделах "8.1.1 Синтаксис JOIN" и "2.5.6 Использование внешних ключей".
Синтаксис FOREIGN KEY в MySQL существует только для совместимости с другими версиями SQL-команды CREATE TABLE, это не делает ничего. Синтаксис FOREIGN KEY без ON DELETE ... обычно используется для документационных целей. Некоторые прикладные программы стандарта ODBC могут использовать это, чтобы произвести автоматические предложения WHERE, но это обычно просто, чтобы перекрыть. FOREIGN KEY иногда используется как проверка ограничения, но эта проверка практически не нужна, если строки вставлены в таблицы в правильном порядке. MySQL поддерживает эти предложения только потому, что некоторые прикладные программы требуют, чтобы они существовали (независимо от того, работают они или нет).
В MySQL Вы можете обойти проблему неработающей конструкции ON DELETE ... добавляя соответствующую инструкцию DELETE к прикладной программе, когда Вы удаляете записи из таблицы, которая имеет внешний ключ. Практически это иногда быстрее и намного более переносимо, чем использование внешних ключей в таблице.
В ближайшем будущем мы расширим реализацию FOREIGN KEY так, чтобы по крайней мере информация была сохранена в файле спецификации таблицы и могла быть получена mysqldump и ODBC. На более поздней стадии мы выполним ограничения внешних ключей для прикладной программы, которая не может легко быть перекодирована, чтобы избежать их.
Много ученых по теории базы данных и программистов чувствуют, что справочная целостность должна быть предписана внутри сервера базы данных. Действительно, во многих случаях этот подход очень полезен. Однако, в разговоре со многими пользователями баз данных авторы наблюдали, что внешние ключи часто неправильно используются, что может вызывать серьезные проблемы. Даже когда все используется правильно, это не волшебное решение для проблемы справочной целостности, хотя это делает все проще в некоторых случаях.
Из-за вышеупомянутых наблюдений авторы не назначали реализации внешних ключей высокий приоритет. Однако, в последние годы ядро пользователей расширилось, и теперь авторы пакета имеют много пользователей, кто хотел бы иметь предписанную поддержку справочной целостности внутри MySQL. Так что в ближайшем будущем внешние ключи все-таки будут реализованы.
Некоторые преимущества применения внешних ключей:
Противопоказания:
MySQL не поддерживает views, но это планируется исправить примерно к 4.1.
Views обычно полезны для разрешения пользователям обращаться к набору отношений как к одной таблице (в режиме только для чтения). Многие базы данных SQL не позволяют модифицировать любые строки в таком представлении: Вы должны делать все модификации в отдельных таблицах.
MySQL обычно используется в прикладных программах и на web-системах, где автор прикладной программы имеет полное управление над применением базы данных. По этой причине views не сочтены очень важными.
Чтобы ограничить доступ к столбцам в MySQL views тоже не требуются: MySQL имеет очень сложную систему предоставления привилегий. Подробности в разделе "10 Общие проблемы защиты и система привилегий доступа MySQL".
Некоторые базы данных SQL применяют -- как начало комментария. MySQL имеет # как символ начала комментария, даже если инструмент командной строки mysql удаляет все строки, начинающиеся с --. Вы можете также использовать стиль комментариев языка C (/* это комментарий */) в MySQL.
MySQL Version 3.23.3 и выше поддерживает стиль комментариев --, только если комментарий сопровождается пробелом. Это потому, что стиль комментария вызвал много проблем с автоматически сгенерированными запросами SQL, которые использовали нечто вроде следующего кода, где мы автоматически вставляем значение payment вместо !payment!:
UPDATE tbl_name SET credit=credit-!payment!
Как Вы думаете, что случится, когда значение payment отрицательное? А вот что. Поскольку 1--1 допустимо в SQL, пакет думает, что начался комментарий типа --. Вряд ли это входит в Ваши планы...
В MySQL Version 3.23 Вы можете использовать: 1-- Это был комментарий
Следующее обсуждение касается Вас, только если Вы управляете MySQL Version 3.23 или ранее:
Если Вы имеете программу SQL в текстовом файле, который содержит комментарии --, Вы должны использовать:
shell> replace " --" " #" < text-file-with-funny-comments.sql \
| mysql database
Вместо обычного решения:
shell> mysql database < text-file-with-funny-comments.sql
Вы можете также редактировать командный файл, чтобы сменить комментарии -- на
продолжение следует...
Часть 1 Mysql - обзор базы данных , основы, назначение и возможности
Часть 2 1.2 MySQL и стандарты - Mysql - обзор базы данных
Часть 3 Вау!! 😲 Ты еще не читал? Это зря! - Mysql - обзор базы данных , основы,
Данная статья про mysql подтверждают значимость применения современных методик для изучения данных проблем. Надеюсь, что теперь ты понял что такое mysql и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL