MySQL *

Всем привет!
Удобно смотреть отчёты через браузер, не надо пользователю никакие программы устанавливать.
Для более удобной работы с данными журнала использования Интернета (WEB) и журналом брандмауэра (FWS) сервера MS TMG их можно загрузить в базу MySQL. Можно написать сколько угодно отчётов по этим данным. Для доступа к отчётам используется веб-интерфейс.
Пример реализации под катом.

Собственно, столкнулся с банальной задачей — есть база, в которой есть масса данных ФИО, написанных латиницей. Зачастую достаточно безграмотно и непредсказуемо транслитерировано. Вроде бы и есть ГОСТ 7.79 (ISO 9), но на практике его далеко не всегда соблюдают.
Задача — есть БД с записями (как правило, ФИО) латиницей. Плохой латиницей. Требуется по русской подстроке поиска в вэб-приложении выбрать из БД (MySQL) записи, похоже транслитерированные на латиницу.

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

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

Однажды мне потребовалось узнать номера улиц и домов Минска. Каково же было мое разочарование, когда я узнал, что полных данных нигде нет, и что делать если появляются новые улицы и дома. Вот тут и пришел на выход OpenStreetMap с открытым кодом и постоянными обновлениями. Беда в том, что карты представляют собой xml документ, объёмом аж целых 2 Гб и информация о домах представлена в таком виде:

<way id="25324320" >
  <nd ref="275904968"/>
  <nd ref="275904882"/>
  <nd ref="275904881"/>
  <nd ref="275904969"/>
  <nd ref="275904968"/>
  <tag k="addr:housenumber" v="17"/>
  <tag k="addr:postcode" v="220013"/>
  <tag k="addr:street" v="улица Якуба Коласа"/>
  <tag k="building" v="yes"/>
 </way>  

Обрабатывать 1.5 Гб данных проще, когда данные упорядочены а не представлены в виде строк. Так мной было принято решения конвертировать данные в БД. Сказано – сделано, в качестве рабочего инструмента выбраны: Eclipse(Java SE) и джентельменски набор денвера.

Вчера Oracle Certification запустила beta-сертификацию MySQL 5.6 DBA и MySQL 5.6 Developer Beta-программа продлится около двух месяцев. В это время у вас есть возможность получить сертификаты за 50 USD

Это первый официальный экзамен по MySQL за очень долгое время: предыдущий был для версии 5.0 и много багов утекло с той поры. Для меня лично это событие значимо ещё и потому, что я принимала активное участие в создании и редактировании вопросов вместе с другими инженерами из команды MySQL Support. А гордиться нам есть чем.

Кто пишет на Node.js и использует MySQL, тот непременно знает, что наш дорогой товарищ Felix Geisendörfer три года назад совершил героический и самоотверженный подвиг: в одиночку разработал очень качественный драйвер для подключения к MySQL, нативно реализовав двоичный протокол этой СУБД на JavaScript. Потом к проекту подключились другие уважаемые товарищи, была реализована поддержка пулов соединений, кластеров, транзакций, восстановление при временной утере соединения и т.д. Сейчас драйвер является самым развитым, хорошо проработанным и активно поддерживаемым из того, что мы имеем в открытых репозитариях npm и github. Удивительно даже, что при хорошо проработанной низкоуровневой реализации, все удобства, которые предоставляет это драйвер для прикладного разработчика, сводятся к одному методу query. Для меня лично, этого очень мало, ну привык дедушка к удобствам для возврата скалярных значений, строк и столбцов в массивы, интроспекции структур БД. Так что, с удовольствием делюсь этими наработками с вами, мои дорогие Хабравчане, но предупреждаю, что все удобства будут на улице. Есть конечно вариант тесной интеграции с драйвером, но FelixGe желает оставить драйвер исключительно низкоуровневым, поэтому я остановился на варианте внешней библиотеки с добавлением к драйверу через примеси. В виде примесей, удобства попали и в платформу Impress, а так же, опубликованы как патч к драйверу. О функционале и вариантах использования далее.

Очень короткая статья, про то как можно использовать HAProxy в качестве балансировщика для multi-master серверов MySQL, таких как Percona или Galera.

Хочу отметить, что эта инструкция родилась в процессе внедрения Zabbix в стенах компании Acronis.
В процессе экспертизы и проведенных мною исследований, она доказала свое право на жизнь и благополучно служит нам верой и правдой день ото дня.

Для тех кто не знаком с HAProxy, цитата о предназначении продукта:

При увеличении нагрузки или посещаемости проекта, рано или поздно вертикальное маштабирование (увеличение ресурсов сервера, таких как память, скорость диска и т.д) упирается в некий предел и не дает ощутимого прироста. В таком случае в ход идет горизонтальное масштабирование — добавление новых серверов c перераспределением нагрузки между ними.
Кроме увеличения мощности, горизонтальное масштабирование добавляет надежности системе — при выходе из строя одного из серверов, нагрузка будет сбалансирована между работающими и приложение будет жить.

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

Предисловие переводчика

Имея совсем небольшой опыт работы с набором WAMP (Windows Apache/MySQL/PHP), я столкнулся с необходимостью его переустановки как с целью обновления версий составляющих его частей, так и с целью установки openssl. Openssl в свою очередь мне необходим для использования composer, а composer для установки Laravel 4. Laravel 4 мне нужна просто из любопытства — хочется попробовать новую версию популярного фреймворка. Теперь вы знаете, что привело меня к переводу этой статьи, на которую я наткнулся в ходе поиска советов бывалых, уже прошедших этот путь людей, на форуме forum.wampserver.com. Статья свежая, от 11 октября 2013 г., возможно кому-то из вас она и пригодится. Итак…

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

Эта статья задумана мной как сборник некоторых интересных моментов по использованию и оптимизации SQL запросов в БД MySQL, на мой взгляд, плохо освещенных в интернете. Так, из статьи вы узнаете о конструкции with rollup, и о том, как переписать подзапросы in и not in на join'ы, а так же обновление и удаление данных в нескольких таблицах — одним запросом, и многое другое. Начнем по порядку.

Привет Хабравчанам!

Рады сообщить, что в ближайшие две недели офис Jelastic навестят настоящие гуру IT-индустрии: Майкл Видениус (или Монти, создатель MySQL), Расмус Лердорф («отец PHP») и Марк Збиковски (бывший архитектор компании Microsoft).


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

Недавно мне поставили такую задачу: Есть много коммивояжеров с ноутбуками которые разъезжают по стране и что-то кому-то впаривают продают.
Т.к. им нужны актуальные данные о наличии товара и ценах, время от времени они подключаются к центральному серверу через интернет и сливают себе обновленные данные.

Условия к задаче:
— Частота и периодичность выхода на связь коммивояжеров неизвестна, ровно как и длительность.
— Должно все работать максимально надежно, потому как коммивояжеры они такие «коммивояжеры».
— Решение должно быть на базе Mysql master-slave replication.

Выводы из условия:

— Для надежности, на стороне клиента(slave) минимум настроек, никаких скриптов по крону, все должно быть внутри mysql.
— Т.к. неизвестно когда и с какой периодичностью будут подключаться к master базе коммивояжеры, binlog на мастере нужно хранить так долго пока все slave не скачают его себе.

Решение:
— Информировать мастер, какие slave и сколько уже «скачали». А точнее в какой позиции самый «ленивый» slave.
— Все остальные binlog можно смело удалять.

Дополнение к циклу переведенных статей.
Статьи: 1-3, 4-6, 7-9, 10-13, 14-15

Информация в статье относится к 5-й части руководства.

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

Введение.

Если отталкиваться от обывательской позиции человека, который разрабатывает базы данных, то внешние ключи – это удобно и упрощает жизнь (в большинстве случаев, всегда есть исключения.). Даже будучи невеждой в реляционной теории баз данных, к осознанной необходимости использования внешних ключей, на определенном этапе своего развития, приходит практически любой практик (утверждение — более относится к начинающим), который не стоит на месте в своем развитии и продолжает мыслить. Даже если он еще не знает, что то, что ему нужно называется связью по внешнему ключу, он начинает самостоятельно организовывать данные определенным образом, разбивать на отдельные таблицы и связывать их между собой. Настолько это становится очевидным.
Но при использовании внешних ключей, даже если не знать такого определения, возникает необходимость следить за связываемыми данными. Рассматриваемым объектом данной статьи является, если так можно сказать, своеобразный спутник, который следует за такой организацией данных. И в данном случае уже гораздо полезнее знать теорию, т.к. это может значительно упростить жизнь в процессе работы с базой данных.

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9, 10-13
Продолжение. Каскадное удаление данных.

14. Другой пример: база данных интернет-магазина.

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

Система интернет-магазина.

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

• Отображение товаров
• Классификация товаров
• Регистрация клиентов
• Добавление товаров в корзину покупок
• Отображение содержимого корзины покупок
• Оформление заказов посетителями
• И т.д.

Определяем сущности и отношения.

Из списка задач мы можем вывести сущности, которые имеют важные роли в нашей системе. Товары, категории, клиенты и заказы – сущности, которые можно найти почти в каждой базе данных интернет-магазина. В данном примере я покажу вам модель, содержащую только следующие сущности: клиент, заказ и товар. Определившись с сущностями, мы можем подумать над связями между ними.

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

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

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

Продолжение.
Предыдущие части: 1-3, 4-6

7. Связь один-ко-многим.

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

Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.

(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.


Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.

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

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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



В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

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

Другие части: 4-6, 7-9, 10-13, 14-15.

Руководство по проектированию баз данных.

1. Вступление.

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

Проект phpMyAdmin появился на свет 9 сентября 1998 года, когда Тобиас Ратшиллер (Ratschiller) выпустил версию 0.9.0. За прошедшие полтора десятилетия phpMyAdmin превратился в один из основных инструментов для администрирования MySQL и других MySQL-подобных баз данных, с гордостью пишут разработчики.

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

К созданию phpMyAdmin причастны 669 разработчиков, а основная группа разработчиков выросла с 1 до 9 человек.

Хотим «phpMyAdmin» (читай web GUI) для ноды

Отсутствие универсальных веб-интерфейсов для управления распространенными СУБД, несколько усложняет освоение Node.js, а разворачивать рядом другой веб-сервер и другой язык с инфраструктурой, ой как не хочется. Открывать порты и управлять базами, подключаясь с другого сервера или со своего рабочего компьютера — это и неудобно и есть соображения безопасности. Поэтому мы решили включить такой инструмент в платформу для веб-приложений Impress, которую анонсировали, о которой я немного писал и которая доступна в открытом коде для всеобщей пользы. Задумка такая: реализовать простой и удобный унифицированный интерфейс для СУБД, которые чаще всего применяются в связке с Node.js, позаботиться о быстром развертывании (просто скопировать папку) и независимости от среды. В бета-версии уже поддерживаются MySQL, MongoDB и в скором времени очередь дойдет до PostgreSQL и Oracle.