Комментарии 75
Прога полезная, пользуюсь около месяца.
Правда, после SQL Server Management Studio долго привыкал: непривычные для меня хоткеи, нет drag&prop скриптов, мешается скрипт, открытый первым (который нельзя закрыть), плохое определение UTF-8 кодировки.
Но работать с программой можно!
Вам спасибо, завтра проверю что нового (я ещё не обновлялся).
Правда, после SQL Server Management Studio долго привыкал: непривычные для меня хоткеи, нет drag&prop скриптов, мешается скрипт, открытый первым (который нельзя закрыть), плохое определение UTF-8 кодировки.
Но работать с программой можно!
Вам спасибо, завтра проверю что нового (я ещё не обновлялся).
Это же старый новый MySQL-Front. Помню его еще 2.5й версией…
отличный клиент, пользуюсь уже наверно больше года. радует что работает и под wine
Новые билды автоматом собираются CI сервером и выкладываются. Там же написано
Latest automatically compiled main executable for HeidiSQL
Мне в нем не нравится, что нельзя принудительно выбирать кодировку клиента, также нельзя выбирать кодировку при импорте/экспорте данных. А в остальном, замечательный клиент, а главное — бесплатный
пользуюсь Mysql Workbench, и проблем не знаю)
dbForge Studio for MySql (для СНГ бесплатно)
— удобный редактор запросов, в том числе визуальный
— удобный редактор объъектов БД.
— отладка процедур и функций, в том числе пошаговая
— и еще всякие приятные плюшки.
— удобный редактор запросов, в том числе визуальный
— удобный редактор объъектов БД.
— отладка процедур и функций, в том числе пошаговая
— и еще всякие приятные плюшки.
Спасибо за наводку, когда буду в винде с БД работать, обязательно посмотрю.
Mysql workbench кроссплатформенный)
Mysql workbench кроссплатформенный)
Поддерживаю, это самый лучший, гибкий и мощный инструмент. К сожалению под Mac OS не смог найти альтернативы достойной dbForge :(
www.devart.com/ru/dbforge/mysql/studio/
Люди, вы только попробуйте это :) Я раньше тоже сидел на HeidiSQL
www.devart.com/ru/dbforge/mysql/studio/
Люди, вы только попробуйте это :) Я раньше тоже сидел на HeidiSQL
К счастью существует MySQL Workbench версию которого можно скачать и под Mac OS
Он только под windows, и это минус.
Там есть diff данных и структуры который удобен и работает.
Спасибо за наводку, поставил.
Первое впечатление — значительно медленнее работает, чем HeidiSQL, если через SSH туннель.
Первое впечатление — значительно медленнее работает, чем HeidiSQL, если через SSH туннель.
Я пользовался им для одного нетривиального проекта (под линуксом и под виндой). И у него есть следующие проблемы:
1. Вылетает без предупреждений и отчетов. Просто падает в совершенно случайных местах.
2. Интерфейс не продуман, особенно в плане клавиатурных сочетаний. Для синхронизации надо нажать далее раз 5, а если была ошибка, то лезть искать ее в логах.
3. Очень криво синхронизируется с мускулом. Теряет ASC/DESC. Медленный.
Резюме — под линукс никаких альтернатив нет вообще :)
1. Вылетает без предупреждений и отчетов. Просто падает в совершенно случайных местах.
2. Интерфейс не продуман, особенно в плане клавиатурных сочетаний. Для синхронизации надо нажать далее раз 5, а если была ошибка, то лезть искать ее в логах.
3. Очень криво синхронизируется с мускулом. Теряет ASC/DESC. Медленный.
Резюме — под линукс никаких альтернатив нет вообще :)
Перешел с phpmyadmin на Chive
Рекомендую dbForge Studio for MySQL от DevArt ( www.devart.com/ru/dbforge/mysql/studio/benefits.html ). Русская версия бесплатна, может подключаться к базе несколькими способами, имеется сравнение и синхронизация данных и структур, продвинутый текстовый и графический редакторы с визуальным построением схем и запросов, система отчетов и администрирования базы. Очень удобная вещь.
Мда, чтобы скачать у них программу, нужно обязательно регистрироваться. Ну что за бред.
Вовсе необязательно — www.devart.com/ru/dbforge/mysql/studio/download.html
Тоже ипользую связку Sqlyog (для синхронизации и PHP-тонеля) и HeidiSQL для всего остального
Если Mac — то рекомендую попробовать Sequel Pro.
Бесплатный, симпатишный, быстрый, гибкий :)
Бесплатный, симпатишный, быстрый, гибкий :)
А как в нем открыть новый таб? Не для SQL запроса, а для всего остального. Чтоб не сохранял каждый раз.
>> для timestamp полей он ставит по дефолту не «DEFAULT CURRENT_TIMESTAMP», а «DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP»
Судя по документации dev.mysql.com/doc/refman/5.0/en/timestamp.html такое поведение для поля timestamp является поведением «по умолчанию». Так что тут дело не в клиенте.
Судя по документации dev.mysql.com/doc/refman/5.0/en/timestamp.html такое поведение для поля timestamp является поведением «по умолчанию». Так что тут дело не в клиенте.
повторяю, он пишнт, что просто курренттаймштамп, а по факту ещё и он апдейт
Я не знаю как это выглядит в интерфейсе, но подозреваю что он просто не может это нигде отразить.
Просто все девелоперы должны знать что timestmap по умолчанию в mysql так работает.
Просто все девелоперы должны знать что timestmap по умолчанию в mysql так работает.
timestamp в mysql ни как не работает, это тип данных. Но для поля можно установить значение по умолчанию CURRENT_TIMESTAMP. В таком случае при добавлении новой записи, если поле имеет значение NULL, ему присваивается текущее время. ON UPDATE это тригер, который присваивает текущее время при каждом обновлении записи. В интерфейсе приложение должно разделять значение по умолчанию и тригер при обновлении.
Все что вы описали «должно» работать, но фактически (раз уж мы имеем дело с mysql) дела обстоят не так.
Создайте MyISAM таблицу и попробуйте сделать там поле типа timestmap.
Для полного контроля я сделал это в консольном клиенте.
так это было:
Как видно, триггер на апдейт устанавливает база а не клиент.
Создайте MyISAM таблицу и попробуйте сделать там поле типа timestmap.
Для полного контроля я сделал это в консольном клиенте.
так это было:
mysql> CREATE TABLE `test` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
`updated` timestamp NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.01 sec)
mysql>describe test;
+---------+------------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+---------+------------------+------+-----+-------------------+-----------------------------+
| id | int(11) unsigned | NO | PRI | NULL | auto_increment |
| name | varchar(20) | YES | | NULL | |
| updated | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
+---------+------------------+------+-----+-------------------+-----------------------------+
3 rows in set (0.00 sec)
Как видно, триггер на апдейт устанавливает база а не клиент.
Всё что я описал работает в MySQL именно так как и должно работать.
При создании новой таблицы, только для ПЕРВОГО поля типа timestamp СУБД выставляет значение по умолчанию CURRENT_TIMESTAMP и сам создаёт тригер, если клиент не указывает своё значение.
Если указать default CURRENT_TIMESTAMP, то тригер создан не будет. Таким образом в интерфейсе можно отобразить всё правильно, по крайней мере Mysql Workbench здорово с этим справляется :)
При создании новой таблицы, только для ПЕРВОГО поля типа timestamp СУБД выставляет значение по умолчанию CURRENT_TIMESTAMP и сам создаёт тригер, если клиент не указывает своё значение.
Если указать default CURRENT_TIMESTAMP, то тригер создан не будет. Таким образом в интерфейсе можно отобразить всё правильно, по крайней мере Mysql Workbench здорово с этим справляется :)
Если я через графический клиент создаю таблицу, то до факта создания таблицы клиент не знает будет ли создан триггер на апдейт или нет.
Поэтому вполне понятно почему этого не видно в интерфейсе.
Если представить что пользователь работает только с консольным клиентом, то в его «интерфейсе» (если его можно так назвать), эффект такой же. Пишете вы одно, а получаете другой результат.
Поэтому, глобально, я считаю, что создание триггера без явного на то указания и есть причина проблемы. Предлагаю закрыть обсуждение, все вроде как поняли суть происходящего.
А то щас обсуждение перерастет в mysql-vs-неmysql холивар.
Поэтому вполне понятно почему этого не видно в интерфейсе.
Если представить что пользователь работает только с консольным клиентом, то в его «интерфейсе» (если его можно так назвать), эффект такой же. Пишете вы одно, а получаете другой результат.
Поэтому, глобально, я считаю, что создание триггера без явного на то указания и есть причина проблемы. Предлагаю закрыть обсуждение, все вроде как поняли суть происходящего.
А то щас обсуждение перерастет в mysql-vs-неmysql холивар.
В последнее время это очень круто — доказывать свою правоту, не зная проблемы.
Вы интерфейс sqlyog`а видели? Использовали его?
То, что mysql по дефолту ставит current_timestamp и вешает триггер, спасибо кэп, вкурсе. Вы видели, как это отображает sqlyog?
Вы интерфейс sqlyog`а видели? Использовали его?
То, что mysql по дефолту ставит current_timestamp и вешает триггер, спасибо кэп, вкурсе. Вы видели, как это отображает sqlyog?
SQLYog его отображает также как и консольный клиент mysql. Т.е никак.
Я имею ввиду что это неявное поведение базы данных а не клиента. И в этом суть проблемы.
Я имею ввиду что это неявное поведение базы данных а не клиента. И в этом суть проблемы.
к сожалению проблема не в этом. Проблема в том, что даже если указать в ёге ЯВНО on update, то потом этого on update НИГДЕ НЕ ВИДНО.
Он просто не умеет показывать в своем интерфейсе такие триггеры.
Если создать триггер через create trigger, то он будет виден в списке триггеров. Но это другое. А такой вот неявный триггер не виден. Вообще. И это таки проблема, да :(
Он просто не умеет показывать в своем интерфейсе такие триггеры.
Если создать триггер через create trigger, то он будет виден в списке триггеров. Но это другое. А такой вот неявный триггер не виден. Вообще. И это таки проблема, да :(
Можете порекомендовать клиента для iPad? Можно в виде веб-морды.
Визуальными конструкторами никогда не пользовался, пишу исключительно на SQL, думаю как и любой другой разработчик, который занимается только СУБД. Для себя испробывал все инструменты. Для Linux платформ лучше белки нету. Для винды:
dbForge Studio for MySQL от DevArt — имел реальный проблемы с форматированием кодов процедур и запросов, с год назад был жутко багнутый. Отладка процедур в MySQL ваще песня — поржал. По мимо этого, тоже ввиду багов, так и не смог нормально настроить клиента на возвращение резалтсета в том же окне без фетчинга всех данных запроса.
жаба которую я клинически неперевариваю, так как раньше работал с PL/SQL Developer, но достойной замены её пока нет. Там нормальный форматтер и удобные макросы. Есть конечно глюки с прерыванием запросов, но это меньшее из зол. В итоге юзаю её сейчас.
dbForge Studio for MySQL от DevArt — имел реальный проблемы с форматированием кодов процедур и запросов, с год назад был жутко багнутый. Отладка процедур в MySQL ваще песня — поржал. По мимо этого, тоже ввиду багов, так и не смог нормально настроить клиента на возвращение резалтсета в том же окне без фетчинга всех данных запроса.
жаба которую я клинически неперевариваю, так как раньше работал с PL/SQL Developer, но достойной замены её пока нет. Там нормальный форматтер и удобные макросы. Есть конечно глюки с прерыванием запросов, но это меньшее из зол. В итоге юзаю её сейчас.
Офигеть, столько пользовался локально и не знал что там есть ssh туннель, поэтому на сервере всегда держал phpmyadmin.
Спасибо :)
Спасибо :)
>Иначе я не могу объяснить, почему чел НЕСКОЛЬКО РАЗ В ДЕНЬ выкладывает новые билды своего проекта.
www.heidisql.com/download.php
Это же ППЦ, сайты реже обновляются, а тут прикладной софт.
Всем приятной недели )
p.s. а ещё на сайте проекта есть иссусий трекер!
И чего? Я так тоже делал когда какие-то мелочи тестил, благо создание билда — минута!
www.heidisql.com/download.php
Это же ППЦ, сайты реже обновляются, а тут прикладной софт.
Всем приятной недели )
p.s. а ещё на сайте проекта есть иссусий трекер!
И чего? Я так тоже делал когда какие-то мелочи тестил, благо создание билда — минута!
Нет ничего лучше Mysql Query Browser ;)
Только версия должна быть правильная. У меня 1.2.17
Только версия должна быть правильная. У меня 1.2.17
Ну а для ssh-туннелей нет ничего лучше Putty ;)
HeidiSQL писали люди, которым ещё не рассказали, что нельзя выполнять сетевые операции в UI-потоке.
Сайт Heidi упал ((( варвары
Пытаюсь запустить всё это под wine
Heidi и plink работают хорошо, но соединится не могу.
Sql error: locst connection to Mysql Server…
Подскажите настройки или как проверить что не работает
Heidi и plink работают хорошо, но соединится не могу.
Sql error: locst connection to Mysql Server…
Подскажите настройки или как проверить что не работает
Так как приходится работать и с MySQL, и c PostgeSQL, и с Oracle, то единственным выходом для себя нашел Navicat (http://navicat.com/).
Могу сказать уверенно – это лучшее из того, что я видел. Есть версии под Mac, Linux и Win.
Могу сказать уверенно – это лучшее из того, что я видел. Есть версии под Mac, Linux и Win.
Я что-то пропустил? Зачем SQL-клиенту нужна поддержка SSH-туннелей, когда SSH может пробрасывать порты на локальный хост?
Пользуюсь Navicat, даже на работу купил лицензию. Рекомендую! Есть синхронизация структуры/данных, перенос и все остальное. Супер.
Только под винду…
Лучший, ИМХО, mysql клиент под Mac — Sequel Pro.
Еще бы что-то подобное было под постгрю...(
Лучший, ИМХО, mysql клиент под Mac — Sequel Pro.
Еще бы что-то подобное было под постгрю...(
Со сколькими мучениями приходится сталкиваться разработчику под windows :)
Пользуюсь года 1,5
Более удобного и шустрого бесплатно клиента под Win я не встречал.
Более удобного и шустрого бесплатно клиента под Win я не встречал.
> Иначе я не могу объяснить, почему чел НЕСКОЛЬКО РАЗ В ДЕНЬ выкладывает новые билды своего проекта.
Выше уже написали, что это автомат. Вообще многие проекты так делают. PHP, например.
Выше уже написали, что это автомат. Вообще многие проекты так делают. PHP, например.
Несмотря на постоянные обновления, некоторые простые вещи там годам не появляются, а многие вещи просто бесят неудобством после Mysql Front.
Например, их синхронизация таблицы из A в B через maintenance не копирует триггеры, затирая страрые (Drop Table же).
Сами тригеры показываются не рядом с полями таблицы, а чёрт знает где отдельно сами по себе. Копирование тригеров через Copy/Paste не работает (в mysqlfront кстаити тоже).
Идиотский после MysqlFront способ отображения полей и индексов. В MysqlFront я сразу в одном месте вижу и ключи, и поля, сразу вижу из чего состоит ключ, и даже в каком порядке. В Heidi же тупо нарисованы ключи рядом с полями, и на отдельной вкладке индексов названия индексов, но чтобы увидеть из чего они состоят, надо каждый раскрывать.
Нет быстрой строки фильтра, как в mysqlfront, где я быстро могу написать условия WHERE.
Нет автосохранения Query, он ещё и каждый раз спрашивает при закрытии сохранять ли и куда.
Неработающий уже много лет модуль Synchronize Database, который по нажатию Analyze тупо в Difference добавляет имя выделенной таблицы.
Буду рад если это всё увидять разработчики и исправят.
Например, их синхронизация таблицы из A в B через maintenance не копирует триггеры, затирая страрые (Drop Table же).
Сами тригеры показываются не рядом с полями таблицы, а чёрт знает где отдельно сами по себе. Копирование тригеров через Copy/Paste не работает (в mysqlfront кстаити тоже).
Идиотский после MysqlFront способ отображения полей и индексов. В MysqlFront я сразу в одном месте вижу и ключи, и поля, сразу вижу из чего состоит ключ, и даже в каком порядке. В Heidi же тупо нарисованы ключи рядом с полями, и на отдельной вкладке индексов названия индексов, но чтобы увидеть из чего они состоят, надо каждый раскрывать.
Нет быстрой строки фильтра, как в mysqlfront, где я быстро могу написать условия WHERE.
Нет автосохранения Query, он ещё и каждый раз спрашивает при закрытии сохранять ли и куда.
Неработающий уже много лет модуль Synchronize Database, который по нажатию Analyze тупо в Difference добавляет имя выделенной таблицы.
Буду рад если это всё увидять разработчики и исправят.
Это все лучше в трекер к ним — code.google.com/p/heidisql/issues/list ;)
Судя по логу www.heidisql.com/download.php, баги фиксяться по паре штук в день.
Судя по логу www.heidisql.com/download.php, баги фиксяться по паре штук в день.
Всё это делал, бесполезно. Вот например code.google.com/p/heidisql/issues/detail?id=3148, ничего не хочет менять.
В итоге если переносить данные через HeidiSQL, то дропаются тригеты этой таблицы. Сами тригеры же вообще ничем не перенести — ни через maintenance/transfer, ни через copy/paste.
Благо хоть старый добрый MysqlFront сейчас тоже стал opensource и развивается.
В итоге если переносить данные через HeidiSQL, то дропаются тригеты этой таблицы. Сами тригеры же вообще ничем не перенести — ни через maintenance/transfer, ни через copy/paste.
Благо хоть старый добрый MysqlFront сейчас тоже стал opensource и развивается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HeidiSQL — клиент к mysql/mssql серверам