MySQL Developer Studio скачать бесплатно - на русском языке для Windows

Смотреть полный скриншот

MySQL Developer Studio - гибкий инструмент разработчика и администратора баз данных MySQL. Он позволяет составлять и исполнять запросы, редактировать данные, управлять пользователями, осуществлять экспорт и импорт данных и многое другое. MySQL Developer Studio упрощает и автоматизирует все основные операции над базой данных.

Основные преимущества:

- Удобная навигация по базе данных. Объекты на сервере представлены в специальном окне Проводника в иерархическом виде, удобном для работы.

- Упрощенное создание и изменение объектов БД. Все часто используемые операции автоматизированы и легко доступны. Для обеспечения дружественного пользовательского интерфейса при работе с объектами БД созданы специализированные визуальные редакторы объектов.

- Мощный набор средств для разработки SQL-запросов. Визуальный редактор запросов позволяет создавать сложные запросы без написания кода.

- Удобное редактирование данных. В табличном редакторе данных есть все, что может понадобиться для просмотра и редактирования данных, включая двоичные данные и длинный текст.

- Легкий экспорт данных. Можно экспортировать все данные в следующие форматы: HTML, XML, MS Excel, текст.

- Гибкое резервирование и восстановление БД.

- Поддержка объектов БД на всём диапазоне версий серверов MySQL от 3.23 до 5.0.18.

Для работы используется платформа .NET.

Скачать бесплатно последнюю версию MySQL

MySQL — свободная система управления базами данных (СУБД). MySQL является собственностью компании MySQL AB, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

MySQL характеризуется большой скоростью, устойчивостью и лёгкостью в использовании, является решением для малых и средних приложений. Наряду с Oracle Database это одна из самых быстрых СУБД на сегодняшний день. Входит в LAMP. Распространение СУБД MySQL на основе GPL и высокая скорость обработки запросов привело к тому, что эта база данных стала стандартом де-факто в услугах сетевого хостинга. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого типа таблиц: пользователи могут выбрать как сверхбыстрые таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и более медленные, но чрезвычайно устойчивые таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующем принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL лицензированию в СУБД MySQL постоянно появляются новые типы таблиц.

Приведенные ниже сборки не являются официальными, так как mysql с версии 5.0.27 распространяет базу данных только в виде исходных кодов.

MySQL 4

Автор: Fix Xxer (PHP Club)

У MySQL версии 4.1 и выше (далее 4.1+) с русскими буквами бывают несколько проблем — рассмотрим их по отдельности.

• Через phpMyAdmin (здесь и далее подразумевается версия умеющая работать с кодировками, т.е. >= 2.6.0) все по-русски, а в скрипт приходят вопросительные знаки.
• Скрипт, заносящий данные в базу, видит русский нормально, а после вставки, как в правильном скрипте, так и в phpMyAdmin-е — знаки вопросов.

Тестирование:

Попробуйте в начале вашего скрипта, но после соединения, выполнить SQL-запрос "SET NAMES кодировка". Где кодировка - та кодировка, в которой у вас (по вашему мнению) данные. Например, для русской Windows кодировки (windows-1251) это будет cp1251, для KOI8-R – koi8r, для UTF-8 – utf8 и так далее. В дальнейшем она будет упоминаться как "кодировка".

• Если буквы (но необязательно слова) стали русскими, значит, данные в базе лежат в правильной кодировке, сама база эту самую кодировку и использует.
• Если буквы стали русскими, а слова нет ("бнопня"), значит, скрипт ожидает данные в другой русской кодировке — пробуйте другие, пока не получится русских слов.

1) Оставить запрос "SET NAMES кодировка" в начале скрипта. Если скриптов много – см. вариант 2.

2) Заставить MySQL автоматически выполнять этот запрос при каждом соединении с ним.

Для этого необходимо в конфигурационном файле MySQL. в секции [mysqld] добавить следующую строку: init-connect="SET NAMES кодировка" .

Однако, следует заметить, что это НЕ будет работать, если пользователь, которым вы подключаетесь к базе имеет привилегию SUPER (а стандартный пользователь root к таким относится, так же как и все созданные через "GRANT ALL PRIVILEGES ON *.* TO. "). Это сделано для того, чтобы в случае ошибки в этом запросе (а его можно изменить во время работы), хоть кто-то мог подключиться к базе и исправить его.

Внимание! Функция mysqli_client_encoding() и сотоварищи, отображает кодировку клиента на момент соединения и не меняют возвращаемое значение в процессе работы. Поэтому не стоит кричать, что кодировка не меняется. Просто делайте, что говорят и смотрите результат работы скрипта. Получить нужное значение можно SQL-запросом "SHOW VARIABLES LIKE 'character_set_client'" .

3) Начиная с версий 4.1.15 и 5.0.13 добавить в секцию [mysqld] или [server] конфигурационного файла MySQL параметр skip-character-set-client-handshake. Этот параметр заставляет сервер игнорировать кодировку, посылаемую клиентом, и использовать указанную серверу. В примере конфигурации ниже этот параметр уже есть.

Русский текст приходит в скрипт как русский, в консольном клиенте тоже все хорошо. Однако не работает сортировка, перевод в верхний/нижний регистр и т.д. Если применить решение из проблемы №1. то либо русский текст становится вопросами, либо mysql_error() возвращает сообщение похожее на "Illegal mix of collations (latin1_general_ci,IMPLICIT) and (cp1251_general_ci,COERCIBLE). ". В тоже время phpMyAdmin русский текст отображает как "крокозябры" (латинские символы с умляутами и т.д.).

Тестирование:

Попробуйте в phpMyAdmin'е выполнить запрос вида "SELECT CONVERT(CONVERT(поле USING binary) USING кодировка) FROM таблица". Где "таблица" и "поле" - соответствующая таблица и поле с русским текстом, а "кодировка" — кодировка из проблемы №1 .

• Если буквы (но необязательно слова) стали русскими, значит текст в базе лежал не в правильной кодировке и его нужно сконвертировать.
• Если буквы стали русскими, а слова нет ("бнопня"), значит неверно выбрана одна из русских кодировок – пробуйте другие, пока не получится русских слов.

1) Установить для MySQL нужную кодировку по умолчанию.

Внимание! Это решение сработает сработает, только если кодировки не переопределены для базы, таблицы или столбца.

default-character-set=cp1251

2) Сконвертировать таблицы в нужную кодировку.

Про то как конвертировать таблицы с неверными кодировками хорошо написано в мануале MySQL. Повторять здесь то же самое не к чему.

MySql и русская кодировка

Проблема возникает, если вы работаете с кодировкой, отличной от UTF-8, и храните в базе данных тексты, к примеру, в кодировке cp1251. Но MySql не всегда использует по умолчанию кодировку cp1251, в частности, не всегда по умолчанию используется эта кодировка для соединений с базой. Из-за этого возникают ситуации, когда в базе тексты хранятся в нормальном читабельном виде, но при выводе этих данных на сайт появляются одни лишь «кракозяблы» (знаки вопросов вместо букв – «. »).

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

Обновлено: Количество запросов уменьшено благодаря прояснению ситуации Бирц`ом (см. комментарии).

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

На серверах, которые предоставляют услуги хостинга для русскоязычных сайтов, чаще всего все в порядке и такой проблемы нет (т.к. у них по умолчанию MySql настроен на работу в первую очередь с кодировкой cp1251). Если ваш сайт использует иностранный хостинг, то, скорее всего, единственным способом решения проблемы будет способ, описанный выше.

Но если же вы имеете возможность подкорректировать конфиг MySql на сервере, тогда есть еще одно решение, реализацию которого я с радостью для себя обнаружил (я-то «догадывался», что можно как-то изменить настройки самого MySql, но как это сделать, не знал)

MySQL и русская кодировка WINDOWS-1251

Сегодня мы рассмотрим, что нужно написать в конфигурационном файле /etc/my.cnf для того, чтобы настроить mysql стандартной сборки на работу с кодировкой cp1251 по умолчанию без всякой перекомпиляции.

Рассмотрим пример конфига на основе MySQL 5.x.

В раздел [mysqld] необходимо добавить следующее:

default-character-set=cp1251

character-set-server=cp1251

collation-server=cp1251_general_ci

init-connect=»SET NAMES cp1251″

Две последние строки принудительно устанавливают кодировку cp1251 для всех запросов.

В раздел [mysqldump] достаточно добавить только

Корректная настройка MySQL для работы с UTF8

Сегодня речь пойдет о MySQL и о настройке UTF8 кодировки по-умолчанию. Тема заезжена, но как я убедился за прошедшую неделю, мало кто в состоянии нормально пояснить какие параметры и куда надо прописать для полноценной работы с UTF8 в MySQL. К сожалению, ситуация на тематических блогах оставляет желать лучшего. Основной тип ответа - приведение соедржимого конфигурационного файла с комментарием типа “попробуй, у меня это работает”.

Основная цель данного поста — выяснить, какие параметры и с какими значениями следует прописать в конфигурационный файл my.cnf (my.ini) для дальнейшей беспроблемной работы с Юникодом.

UTF8 на данный момент у меня успешно работает в Мастер-Слейв конфигурации:

• MySQL версии 5.1.66
• Два сервера CentOS версии 6.3
• Репликация между серверами Master-Slave на базе SSL

Любой внешний клиент в состоянии корректно работать с UTF8 базой (проверено на EMS Manager for MySQL c Windows 8 x64).

Все опции и настройки я привожу для версии сервера 5.1.x, однако с минимальными (а то и вовсе без оных) изменениями все это будет работать и на версиях 5.5.x и 5.6.x.

Довольно часто приходится видеть в ответах на вопросы о настройке UTF8 следующее:

Предполагается, что после вставки всего этого добра (тут кстати есть противоречащие друг другу опции) в конфигурационный файл my.cnf (my.ini) магический Юникод начнет работать.

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

Главный раздел по описанию кодировок (character sets ) и их представлений (collations - используется например при сортировке) в контексте сервера, базы, таблиц — это секция 10.1.3. Specifying Character Sets and Collations .

Символьная кодировка может быть задана для:

1. сервера,
2. базы данных,
3. таблицы и
4. колонок в таблице.

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

Все параметры могут быть переданы серверу тремя разными способами:

1. через командную строку mysqld
2. через конфигурационный файл my.cnf (my.ini)
3. через опции компиляции .

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

Кодировка (characher set) - набор используемых символов.

Представление (collation) - набор правил для сравнения символов в наборе.

Тут есть несколько фундаментальных вещей которые надо понимать.

Основные параметры используемые в контексте сервера — это character_set_server и collation_server. Оба параметра влияют на определение кодировки и отображения сервера MySQL.

Можно задать оба параметра либо только один из них. При этом важно знать как задача того или иного влияет на определение отсутствующего:

Заданы оба - используются указанные кодировка и ее представление,

Задана только кодировка — ее представление выставляется по умолчанию для данного типа кодировки. Что это значит? Для каждого типа кодировки есть ее дефолтное представление, например, дефолтная кодировка сервера - latin1. а дефолтное отображение для нее - latin1_swedish_ci. Посмотреть соответствие кодировки и ее дефолтного представления можно используя команду:

SHOW COLLATION LIKE ‘your_character_set_name’;

Поле Default дает ответ о представлении выбранной кодировки.

В нашем случае, при настройке дефолтной кодировки в UTF8, параметры должны быть определены, так как могут быть использованы при определении кодировки или представления базы данных :

PHP на русском: Функция mysql_set_charset() - Устанавливает кодировку клиента

mysql_set_charset — Устанавливает кодировку клиента

Данное расширение устарело, начиная с версии PHP 5.5.0, и будет удалено в будущем. Используйте вместо него MySQLi или PDO_MySQL. Смотрите также инструкцию MySQL: выбор API и соответствующий FAQ для получения более подробной информации. Альтернативы для данной функции:

Устанавливает кодировку по умолчанию для текущего соединения.

Here's an example of how to use this feature :

I'm using PHP 5.2.5 from http://oss.oracle.com/projects/php/

I wanted to store arabic characters as UTF8 in the database and as suggested in many of the google results, I tried using

mysql_query("SET NAMES 'utf8'");

mysql_query("SET CHARACTER SET utf8 ");

but it did not work.

Using the following, it worked flawlessly

$link = mysql_connect('localhost', 'user', 'password');

mysql_set_charset('utf8',$link);

Once this is set we need not manually encode the text into utf using utf8_encode() or other functions. The arabic ( or any UTF8 supported ) text can be passed directly to the database and it is automatically converted by PHP.

Проблемы с кодировкой в MySQL версий 4

Если из базы выводятся вопросики, то после соединения с сервером выполняем волшебный запрос

set names кодировка

Параметр "кодировка" должен соответствовать кодировке, в которой выводятся страницы на сайте.

set names utf8

Если это не помогло, и всё равно идут вопросики или крокозябры - значит, криво настроена кодировка таблиц. В этом случае см. рис.1 п. "Исправление БД" ниже.

Если выводится нормально, но сортировка хромает - см. туда же.

Примечания:

1. Вместо запроса SET NAMES следует по возможности применять функцию mysql_set_charset() или аналоги. Подробнеее см. ниже

2. Кодировка UTF-8 называется в mysql utf8. а Windows-1251 - cp1251

До версии 4.1 кодировку данных в MySQL можно было задать только одну на всех. Теоретически, ничто не мешало в одной таблице хранить данные в юникоде, а в другой - в KOI-8. Так все и поступали: в конце концов, для БД любые данные - это всего лишь набор цифр. Что в неё положил - то она тебе и вернёт. Но правильный поиск и сортировка работали только для данных, которые были в кодировке, совпадавшей с настройками MySQL.

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

Во-первых, для каждого поля в таблице были введены два параметра: кодировка (CHARACTER SET) и правила сравнения (COLLATION).

Кодировка - это понятно. Говорим базе, в какой кодировке лежат наши данные.

Правила сравнения задают порядок сортировки и сравнения данных при поиске.

COLLATION жестко привязан к CHARACTER SET-у и может быть задан только из поддерживаемых кодировкой. Проще говоря, начало названия COLLATION должно совпадать с CHARACTER SET. К примеру, для кодировки utf8 можно задать правила сравнения utf8_bin, но нельзя cp1251_bin.

Обычно у каждой кодировки есть, как минимум, два набора правил сравнения - имякодировки_bin и имякодировки_general_ci. Первый сравнивает в лоб по кодам символов, а второй - регистронезависимо, учитывая совпадающие символы. COLLATION имякодировки_general_cs сравнивает регистрозависимо, отличаясь от _bin тем, что учитывает совпадающие символы ("е" и "ё" в русском языке), а также, при сортировке, ставит на место те символы, которые идут в кодировке не по порядку (например "ё" в 1251).

Если для поля не указан COLLATION, то он берется по умолчанию. К примеру, для utf8 - utf8_general_ci. В большинстве случаев COLLATION по умолчанию устраивает пользователя, а это значит, что его задавать не нужно. То есть, достаточно указать только кодировку.

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

Кодировку (и сортировку) можно указывать для каждого отдельного поля. Если они не указаны, то при создании таблицы берутся из кодировки, указанной для этой таблицы. Если при создании таблицы кодировка не указывается, то она берется из параметров database. Так же и при создании database - либо задаются явно, либо берутся из параметров сервера.

Во-вторых, появилась необходимость говорить базе данных, в какой кодировке мы записываем или хотим получить свои данные. То есть, появилось такое понятие, как кодировка клиента. Здесь и кроется ответ на вопрос - "откуда берутся "вопросики"? Они появляются, если кодировка таблицы не совпадает c кодировкой клиента.

Соответственно, в MySQL появились две новые команды

set character_set_client

set character_set_results

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

Из приведенных объяснений должно быть ясно, что для беспроблемной работы нам надо сделать всего две вещи:

1. Указывать правильную кодировку клиента.

Это можно сделать либо в настройках сервера в my.ini, либо тем самым запросом SET NAMES.

2. Создавая таблицы, не забывать указывать правильную кодировку для них.

Это можно сделать несколькими способами.

Самое простое - это указывать кодировку и правила сравнения прямо в коде CREATE TABLE. Пример:

CREATE TABLE `chartest` (

`name` varchar(10) default NULL

) ENGINE=MyISAM CHARACTER SET=utf8

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

Как мы помним, при создании таблиц, если для них не указывается collation и charset, эти параметры берутся из настроек database.

Следовательно, надо попытаться изменить эти настройки.

сначала смотрим, какие они сейчас: заходим в консоль и пишем

use `mydb`

show variables like "character_set_database";

Этот запрос выведет кодировку базы mydb по умолчанию.

Если она нас не устраивает, то пытаемся переопределить настройки самостоятельно

alter database `mydb` character set utf8;

Если запрос прошел успешно, то проверяем ещё раз, и, если все нормально, то начинаем создавать таблицы или заливать дамп.

Если таким образом сделать не удалось (не хватает прав), то варианта только два - или обращаться к провайдеру, чтобы он сам поменял настройки, или дописывать COLLATION И CHARACTER SET ко всем создаваемым таблицам вручную.

Как следует предыдущих объяснений, кодировка клиента должна соответствовать реальной кодировке поступающих данных. В этом случае, даже если данные лежат в другой, то всё равно никаких проблем не будет - MySQL автоматом перекодрует туда и обратно.

Проведем эксперимент. Для него нам потребуется MySQL, установленная под Windows. Для тех, у кого другая ОС, я думаю, поменять кодировки в терминале проблемы не составит.

Для демонстрации возможностей перекодировки воспользуемся тем фактом, что по умолчанию консоль windows настроена на старую кодировку DOS - 866. То есть, сначала мы создадим таблицу в этой кодировке и запишем в неё данные, а потом попробуем общаться с базой в другой кодировке.

Сначала запустим командный интерпретатор cmd.exe и установим в свойствах окна шрифт Lucida Console.

затем вызываем консоль mysql:

C:\MySQL\bin\mysql.exe -uroot test

В консоли пишем:

set names cp866;

CREATE TABLE ct (`name` varchar(10) default NULL)CHARACTER SET=cp866;

insert into ct values ('Вова');

select * from ct;

Если мы все сделали правильно, то вывод будет таким: