MySQL *

денормализация — это зло, или просто надо уметь её готовить?

Денормализация- это не результат кривых рук. Это не недоделанная нормализация, это намеренное нарушение нормальных форм, для увеличения производительности.
Вопрос о денормализации у меня возникал не раз. Каждый раз, когда приходилось идти на сделку с совестью, нарушая принципы нормальных форм, оставалось ощущение неудовлетворённости, ложное осознание своей некомпетентности. Со временем, при работе в команде, обнаружилось, что это не только моя проблема. Настало время разобраться: денормализация — это зло, или просто надо уметь её готовить?

Задача

Задача такая же как и в предыдущей статье, только применимо к MySQL.

Грабли

Хорошая новость ребята! В MySQL нет проблемы с рекурсивными триггерами! Разработчики MySQL просто тупо лочат изменяемую таблицу даже на уровне триггера, вот редиски. Но, собственно, нас может остановить только отключение электричества.
Есть небольшая лазейка, с… объединенными таблицами. Хотя я не нашел в документации подтверждения того, что это так специально было задумано, но и отрицания тоже не было. Правда есть вероятность того, что эту лазейку могут прикрыть, хотя я не вижу в этом смысла.
Увы, механизм триггеров в MySQL новый и довольно сырой, что накладывает некоторые ограничения на его использование, но все же его достаточно для решения нашей задачи.

Доброго времени суток. Недавно я задался вопросом о том, как делать горячие BackUp`ы MySQL-серверов — ниже компиляция из прочитанного. Заранее хочу сказать, что данный пост является скорее большой заметкой, чем полноценной статьёй. Я намеренно уклоняюсь от описания синтаксиса — на эту тему уже немало написано — я же ставил перед собой другую цель — составить краткий обзор основных методов с характерными особенностями:

Хочу поделиться простым эмпирическим методом, который я использую для определения того, в каком порядке должны идти столбцы в составном индексе. Этот способ подходит не только для MySQL, он также применим к любым СУБД, в которых используются b-tree индексы.

Давайте начнем с запроса, который возвращает пустой результат, но при этом делает полный скан таблицы. EXPLAIN покажет на нем, что нет доступных индексов (т.е. possible_keys = NULL)

SELECT * FROM tbl
WHERE
  status='waiting' AND
  source='twitter' AND
  no_send_before <= '2009-05-28 03:17:50' AND
  tries <= 20
ORDER BY date ASC LIMIT 1;


Когда Ларри Эллисон, директор Oracle, объявил в понедельник о покупке компании Sun, он ни словом не обмолвился о MySQL, своём конкуренте на рынке малых СУБД. Именно этот сегмент остаётся непокрытым в продуктовой линейке Oracle. Все хорошо помнят, как страстно Ларри Эллисон жаждал завладеть этой шведской компанией три года назад. В течение всего 2006 года Ларри Эллисон неоднократно предлагал выкупить MySQL, но трое друзей-шведов, основателей MySQL, неизменно отвергали его предложение от «империи зла», взлёт которой произошёл благодаря сотрудничеству с ЦРУ, после чего MySQL в итоге продалась Sun.

Теперь же мечта Эллисона сбылась, и он даже не говорит, что купил Sun только ради MySQL.

В свете всех известных фактов очень странно смотрятся размышления некоторых аналитиков о том, что MySQL не является конкурентом Oracle. Это слишком узкий взгляд на вещи, потому что не принимаются в расчёт долговременные планы Эллисона, а также перспективы развития самой MySQL (например, в версии 5.4 этой СУБД уже появилась поддержка 16-процессорных серверов x86, а по некоторым тестам производительность выросла на 40000%).

Кстати, по странной случайности выход MySQL 5.4 был запланирован на 21 апреля, но за день до этого произошла сделка с Oracle.

via betanews

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

Последнее время оживилась публика с вопросом случайной выборки из таблицы. Решений по оптимизации полно, и нового сейчас я вам наверное ничего не покажу, просто напомню про основные методы оптимизации — упрощение запроса и индексацию. Без предисловий про фриленсеров, сразу к делу ;)

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

На одном форуме задали вопрос о том, как правильно посчитать разность дат в MySQL для учета стажа сотрудника. На первый взгляд вопрос оказался простым, но при детальном рассмотрении все оказалось куда интереснее.

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

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

SET @mytable='users';
SELECT * FROM @mytable;

Такая конструкция работать не будет. А что же делать, чтобы она заработала?

Добрый день. Я расскажу об одной из забавных особенностей оптимизатора MySQL 5.1.30, которая заставляет перед обновлением внимательно проверить запросы.
Для любопытных: «теперь SET-выражения выполняются не в порядке следования выражений слева направо, а в порядке следования обновляемых таблиц».

Базы данных иногда пропадают. Человеческий фактор и всё-такое… Если вы не делали бекапов (а надо бы) или они уже устарели, не отчаивайтесь, — есть ещё возможность восстановить утерянную информацию.

PostgreSQL и MySQL — две самых распространенных системы управления базами данных в интернете.



MySQL используется в таких высоконагруженных проектах как Wikipedia, facebook, flickr, Digg, YouTube, на хабрахабре и практически на всех сайтах, работающих под управлением Drupal и Wordpress.

Не уступает и Postgres — без него не работал бы Skype, его используют популярные в Америке социальные сети myyearbook.com и hi5.com, не работали бы без него и наши отечественные Мой Круг, smotri.com и Мир Тесен.
Свежие версии Друпала декларируют поддержку PostgreSQL, а вместо Wordpress можно использовать Movable Type. Из других любопытных приложений, использующих Postgres можно вспомнить 1С: Предприятие 8 и некоторые другие корпоративные информационные системы.

Какая же СУБД лучше? Для каких задач? Как одни и те же задачи решают в разных средах?

22 января 2009 года в Москве при поддержке клуба «Бизнес в стиле .RU» состоится уникальное событие — cовместная встреча московских групп пользователей MySQL и PostgreSQL.

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

Предварительный состав участников встречи:

• Константин Осипов, Sun/MySQL
• Виктория Резниченко, Sun/MySQL
• Алексей Рыбак, Badoo.com
• Фёдор Сигаев, PostgreSQL Global Development Group
• Олег Бартунов, PostgreSQL Global Development Group
• Андрей Смирнов, NetStream

Ведущий встречи — Николай Самохвалов, компания Постгресмен.

Встреча пройдет в здании Государственного университета — Высшей школы экономики на Покровском бульваре, дом 11 (станции метро Курская/Чкаловская или Китай-город), в аудитории В-201. Вход — со стороны Покровского бульвара, через корпус Е.

Начало — в 19-00.

Для участия во встрече необходимо пройти предварительную регистрацию: reg.styleru.net/registration/pgsqlvsmysql

Итак!
1. Регистрируемся.
2. Приходим к 19-00 на главный вход.
3. Показываем документ (паспорт, водительское удостоверение, студенческий билет, что угодно, где есть ваше имя и фамилия).
4. Проходим по указателям до аудитории В-201 и общаемся с докладчиками!

Может это и правильно, но как-то неожиданно.

select
'2008-02-27' + INTERVAL 1 YEAR, -- 2009-02-27
'2008-02-28' + INTERVAL 1 YEAR, -- 2009-02-28
'2008-02-29' + INTERVAL 1 YEAR, -- 2009-02-28
'2008-03-01' + INTERVAL 1 YEAR; -- 2009-03-01


UPD По результатам обсуждения резюмирую:
а) это стандартное поведение и других СУБД и более того
б) данный способ расчета годового периода узаконен и применяется в офлайн.

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

Что такое представление?

Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.

Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.

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

Механизм блокирования в MySQL

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

По долгу службы мне пришлось сталкиваться с курсорами. Хотелось бы рассказать, что это такое и о некоторых особенностях работы с ними. Официальная документация тут — dev.mysql.com/doc/refman/5.1/en/cursors.html Википедия даёт такое определение курсору курсор:

Вступил недавно в локальный оффлайн-холивор на тему форматирования длинных SQL-запросов.

Собственно, весь холивор сводится к тому, что удобнее читать — INNER JOIN ДО таблицы, или ПОСЛЕ неё, а так же — AND — до или после обьявления условия.

Два варианта и вопрос к хабровчанам под катом:

Думаю у многих возникала необходимость хранить файлы, связанные с записью в таблице. Это может быть картинка к новости, аватар, загруженный пользователем файл — да все, что угодно. Обычно в этому случае поступают просто — файл ложится в файловую систему, а ссылка на него — в запись БД.
Но у такого классического похода множество недостатков:

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

Больше о проблемах, возникающих при хранении файлов отдельно от БД можно почитать в презентации SQL Antipatterns, раздел Phantom Files, страница 60. Кстати, автор презентации предлагает решение — хранить файлы прямо в БД, в поле типа BLOB. Правда следует замечание, что это должно быть взвешенное решение в каждом конкретном случае. Ведь при таком способе хранения файлов вебсервер должен при каждом запросе вызывать некий скрипт, который будет извлекать файл из БД и отдавать пользователю, что неминуемо отрицательно скажется на производительности.
Для поиска решения данной проблемы был проведен мозговой штурм и придумано несколько вариантов решения проблемы: