Рубрики
Базы данных

Mysql: SPLIT function и правильный подсчет количества символов.

Столкнулся на днях с задачкой разделения строки состоящей из нескольких значений, разделенных некоторым разделителем, на отдельные значения на уровне базы данных. Во всех приличных БД все это уже есть из коробки, а вот в MySQL нет. Пришлось написать самому. В общем-то в нете полно решений, но во всех, что я видел, есть один большой недостаток, или даже баг. Заключается он в том, что везде требуется вычислять длину подстрок и делается везде это через функцию LENGTH(). Однако если внимательно прочитать описание этой функции, то можно узнать, что она считает длину строки в БАЙТАХ! То есть если вы используете какую-либо двухбайтную кодировку для хранения строк, например UTF-8 (* вообще станно, если вы до сих пор используете какую-то другую 🙂 *), то эта функция вернет совсем не тот результат, который вы ожидаете. Для того, чтобы избежать этой проблемы, есть другая функция CHAR_LENGTH(), которая делает именно то, что и надо — считает длину строки в символах. Что же до функции разделения строки на значения, то вот мой вариант:

CREATE FUNCTION `SPLIT_STRING`
(    str VARCHAR(2000), 
     delim VARCHAR(12), 
     pos INT ) 
RETURNS varchar(255) CHARSET utf8
COMMENT 'Разделение строки по делимитеру'
RETURN
     REPLACE(
          SUBSTRING(
               SUBSTRING_INDEX(str, delim, pos),
               CHAR_LENGTH(
                    SUBSTRING_INDEX(str, delim, pos - 1)
               ) + 1
          ),
          delim,
          ''
     )

На входе 3 параметра: сама строка, строка-разделитель и номер позиции значения. Если такого разделителя нет, вернется вся строка, позиция значения считается с 1. Вот примеры:

mysql> select SPLIT_STRING('qwe,asd,zxc', ',', 1);
+-------------------------------------+
| SPLIT_STRING('qwe,asd,zxc', ',', 1) |
+-------------------------------------+
| qwe                                 |
+-------------------------------------+
1 rows in set (0.01 sec)

mysql> select SPLIT_STRING('qwe,asd,zxc', ',', 2);
+-------------------------------------+
| SPLIT_STRING('qwe,asd,zxc', ',', 2) |
+-------------------------------------+
| asd                                 |
+-------------------------------------+
1 rows in set (0.01 sec)

mysql> select SPLIT_STRING('qwe,asd,zxc', '$', 1);
+-------------------------------------+
| SPLIT_STRING('qwe,asd,zxc', '$', 1) |
+-------------------------------------+
| qwe,asd,zxc                         |
+-------------------------------------+
1 rows in set (0.01 sec)

That’s all folks!

Рубрики
Администрирование

MySQL и регистро-зависимость имен в MacOS X

Всем привет.
Столкнулся тут на днях со следующей проблемкой. Я работаю на Mac OS X, и поэтому все необходимое для разработки ПО у меня стоит на моем компе, тот же Апач, Пых (они вообще идут из коробки) ну и Майскуль.
Так вот, решил я для одного нового проекта заюзать MySQL Workbench. Это такая утилита, в которой можно построить UML-схему базы данных, все красиво разрисовать и потом слить эту структуру в конечную БД, так же есть Reverse Engineering. В общем, первое сливание текущей структуры из БД прошло гладко, а вот первая же заливка изменений в БД уже не получилась. Не смотря на то, что Workbench честно показывал изменения, после накатывания аптейта, он все равно продолжал считать, что все структуры разные. Дело в том, что я люблю называть таблицы красивыми именами, отражающими действительность, с заглавными буквами, разве что в дополнение к CamelCase стилю еще разделяю слова символом подчеркивания. Так вот после долгих изучений и изысканий обнаружилось, что установки по умолчанию в MySQL Server на Mac OS, не очень подходят для моего случая.

Как известно, в MySQL, база данных соответствует определенной директории на сервере, и каждая таблица хранится в виде файла (или нескольких в зависимости от движка). Поэтому регистро-чувствительность ОС играет немаловажную роль в обработке регистро-чувствительности при разрешении имен в базе данных. Это означает, что если ваш сервер на винде, то ему пофиг на регистр, в *nix-подобных системах же наоборот, регистр имеет значение, за исключением Mac OS, которая вроде как юникс, а файловая система там HFS+, которая не очень чувствительна к регистру.

В MySQL сервере есть 2 системных переменные которые имеют отношение к регистру имен, это lower_case_file_system и lower_case_table_names. Первая переменная отражает регистрочувствительность файловой системы, где расположено хранилище, оно может принимать всего два значения: OFF — фс чувствительная к регистру и ON — не чувствительна.
Вторая переменная, lower_case_table_names, отражает механизм, как происходит сравнение имен и способ их хранения. 0 означает, что имена сохраняются в том виде, в котором были заданы и сравнение чувствительно к регистру. При значении 1, имена таблиц хранятся в нижнем регистре и сравнение не чувствительно к регистру. В случае 2, имена хранятся как есть, но сравнение происходит в нижнем регистре.

По умолчанию эти переменные принимают вот такие значения на Mac OS X:

kostik@KOsTIK: ~> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.1.49 MySQL Community Server (GPL)
mysql> select @@lower_case_table_names;

+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        2 |
+--------------------------+
1 row in set (0.00 sec)

mysql> select @@lower_case_file_system;
+--------------------------+
| @@lower_case_file_system |
+--------------------------+
|                        1 |
+--------------------------+
1 row in set (0.00 sec)

И вот такие на *nix (проверил на Linux/FreeBSD)

kostik@linux: ~> mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 49773
Server version: 5.1.51 MySQL Community Server (GPL) by Remi

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        0 |
+--------------------------+
1 row in set (0.00 sec)

mysql> select @@lower_case_file_system;
+--------------------------+
| @@lower_case_file_system |
+--------------------------+
|                        0 |
+--------------------------+
1 row in set (0.00 sec)

 

Если почитать описание этих переменных на сайте mysql (тут), то там написаны замечательные рекомендации по выставлению правильных параметров переменной lower_case_table_names. Если лень читать, то основная мысль: если вы используете InnoDB как основной движок, то поставьте везде этот параметр в 1.
Самый простой способ — это прописать эту переменную в файле конфигурации my.cnf в секцию [mysqld] и рестартануть Mysql сервер.

В общем-то я не открыл ничего нового, все это можно найти в офф. документации на сайте, статья: Identifier Case Sensitivity дает более развернутое описание этой ситуации. Рекомендую прочитать.
Вот и все!

Рубрики
Oracle

Подключение плагинов для мониторинга стороннего ПО в Oracle EM Grid Control на примере MySQL и MS SQL Server.

Это шестой пост из серии «Управление инфраструктурой Oracle с помощью EM Grid Control 11g«. В нем я хочу рассказать о том, как можно расширить возможности EM Grid Control по мониторингу разного стороннего ПО. В EM для этого предусмотрен механизм плагинов мониторинга.