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.4.5. Вопросы, связанные с Проблемой-2000

Сам MySQL не имеет проблем, связанных с Проблемой-2000 (Y2K):

  • В MySQL используются функции времени Unix, поэтому проблемы с датами, вплоть до 2069, исключены. Принимается, что все двузначные значения годов находятся в диапазоне с 1970 по 2069, поэтому число 01 в столбце с типом year MySQL обрабатывает как 2001.

  • Все MySQL-функции, обрабатывающие даты, хранятся в одном файле sql/time.cc. Их код был написан очень тщательно, чтобы застраховаться от проблем, связанных с 2000-м годом.

  • В версиях MySQL 3.22 и более поздних в столбцах с новым типом YEAR, который обеспечивает хранение нулевого 0 года и значений лет от 1901 до 2155 в одном байте, а также отображение дат при помощи 2 или 4 знаков.

Проблемы, связанные с 2000-м годом, могут возникнуть в приложениях, которые используют MySQL так, что это может оказаться небезопасным с точки зрения Y2K. Например, во многих старых приложениях для хранения и обработки значений годов используются 2-значные величины (которые можно трактовать неоднозначно), а не 4-значные. Эта проблема может быть урегулирована при помощи приложений, которые используют 00 или 99 как «отсутствующие» индикаторы значений.

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

Приведенный ниже код является наглядной демонстрацией того, что в MySQL Server проблемы с датами вплоть до 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
    -> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
    -> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
    -> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
    -> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
    -> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
    -> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
    -> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
    -> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
    -> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
    -> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
    -> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
    -> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
    -> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

Можно видеть, что при использовании типов DATE и DATETIME проблем с датами будущего не возникнет (эти типы «справляются» с датами вплоть до 9999 года).

Тип TIMESTAMP, который используется для сохранения текущего времени, имеет диапазон только до 2030-01-01. В 32-разрядных машинах TIMESTAMP тип имеет диапазон от 1970 до 2030 (значение со знаком). В 64-разрядных машинах этот тип «справляется» со значениями времени до 2106 года (значение без знака).

Таким образом, даже несмотря на то, что MySQL является Y2K-совместимым, ответственность за однозначную интерпретацию значений даты ложится на плечи пользователя. See Раздел 6.2.2.1, «Проблема 2000 года и типы данных», где приведены правила по работе MySQL с входными данными, которые имеют неоднозначные значения даты (данные, содержащие 2-значные значения года).



Просмотров 7756