СУБД MySQL предлагает много функций, работающих с календарными данными. Более подробную информацию о функциях, работающих с календарными данными, можно найти в приложении В, Операторы и функции .

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

CREATE TABLE y table(y YEAR)

INSERT INTO y table VALUES(68), (69), (99), (00) SELECT * FROM y table +------+

I у I

+------+

I 2068 I I 1969 I i 1999 i I 0000 i +------+

Совет

Обратите внимание, значение 00 было преобразовано в 0000, а не 2000 Это произошло потому, что значение О является допустимым значением для данных типа YEAR Для того чтобы получить значение 2000, добавьте строку О или 00 . Для того чтобы быть уверенным, что это строковое, а не числовое значение, добавьте его с помощью функции CONCAT() Эта функция I, возвращает строковые данные независимо от типа данных параметра.

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

Выбор типа столбца

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

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

в этом случае потребуется больше памяти, так как числовой формат эффективнее строкового. Из-за различия в обработке чисел и строк, запросы будут интерпретироваться по-разному. Число 2 меньше числа 11, но строка 2 , больше строки 11 . Эту проблему можно разрешить, преобразовав строку в число:

SELECT col name + О As num ... ORDER BY num

Решена ли проблема 2000 года в СУБД MySQL?

Сама по себе СУБД MySQL совместима с 2000 годом. Все даты хранятся в фомате с 4-символьным представлением года Но решение этой проблемы возлагается на разработчика. В действительности проблема интерпретации двухцифрового года лежит не в плоскости СУБД MySQL, а в постоянном желании человека упростить ввод и ввести тем самым неоднозначные данные. Если вы согласны на такой риск - вперед! Вы принимаете рискованное решение и правила работы СУБД MySQL будут адекватны во многих случаях. Но существуют ситуации, когда без четырех цифр не обойтись. В качестве примера можно привести даты рождения и смерти президентов CLUA, начиная с XVIII века и до наших дней. В этом случае выбор двухцифрового обозначения года был бы явной ошибкой.

Прибавление нуля сделает сортировку сортировкой цифровых значений. Но есть ли смысл так поступать? Вероятно, нет. Обработка строкового значения как цифрового вызывает массу сложностей. Так, потребуется операция преобразования из строкового формата в цифровой формат каждого столбца. Это неэффективно. Если этот столбец будет задействован в вычислениях, это не позволит индексировать таблицу по данному столбцу, что, в свою очередь, замедлит работу запросов. Такого снижения эффективности не произойдет, если первыми столбцами таблицы будут цифровые столбцы. Вот так простое решение по выбору типа представления данных возымеет влияние на объем памяти, обработку запросов, производительность системы.

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

Какого рода данные будут храниться в столбце? Числа? Строки? Даты? Несмотря на то, что вопрос очевиден, его необходимо рассмотреть детально. Конечно, в виде строки можно представить любые данные. Однако только что было показано, что для цифровых данных будет эффективнее использовать соответствующие данные. (Это справедливо и в случае с датами и временем.) Однако судить однозначно о типе данных очень трудно. Особенно, когда это чьи-то данные. Очень важно задать будущему хозяину данных вопросы о природе данных, которые будет содержать создаваемая таблица.

Каков диапазон значений? Если это целые числа, будут ли они всегда неотрицательными? Если да, то можно воспользоваться параметром unsigned. Если это строковые данные, - попадают ли они в определенное множество значений? Если да, то можно воспользоваться типом set.

Существует определенная взаимосвязь между диапазоном типа и объемом памяти, который требуется для хранения данных такого типа. Насколько объемные данные вам потребуются? В случае чисел можно выбрать как сверхмалые типы с офаниченным диапазоном значений, так и сверхбольщие с практически неограниченным диапазоном значений. В случае строки их можно сделать большими или маленькими и не объявлять CHAR {255), если доподлинно известно, что все они будут иметь менее 10 символов.

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

Каким образом будут сравниваться значения? Операции сравнения строк могут быть чувствительны к регистру. Выбор типа может влиять на сортировку, которая также базируется на сравнении.

Будете ли вы индексировать столбец? Если да, то это влияет на выбор типа столбца. Некоторые типы данных не индексируются. Это типы blob и text. В старых версиях индексированный столбец обязательно должен быть объявлен с параметром not null. В свою очередь, это влияет на возможность присваивать пустые значения.

Теперь рассмотрим более детально каждый из вышеперечисленных аспектов. Но перед этим позвольте подчеркнуть один момент. При создании таблиц мы стремимся к тому, чтобы они имели оптимальный тип, но если на этом этапе была допущена ошибка, это не беда. Ошибку можно исправить позже с помощью оператора alter table. Так, например, при необходимости (если данные занимают больше места, чем предполагалось) можно заменить тип smallint на meduimint. Задача может быть и сложнее: поменять тип char на enum. В версиях больше 3.22 для получения информации о столбцах таблицы можно воспользоваться функцией procedure analyse(). С помощью этой функции можно выяснить, чему равняются максимальное и минимальное значения диапазона и определить оптимальный тип, который покроет весь диапазон. Это поможет выбрать меньший тип, что, в свою очередь, поможет оптимизировать производительность запросов, которые будут обрабатывать данные таблицы, и уменьшить объем памяти, требующейся для хранения данных таблицы.