LINUX.ORG.RU

Компания JetBrains выпустила финальную версию IDE для баз данных

 data grip, , ,


1

3

JetBrains выпустила финальную версию IDE для баз данных. Продукт ранее называвшийся 0XDBE теперь получил имя DataGrip.

Желающие ознакомиться с новой версией могут сделать это на сайте компании: https://www.jetbrains.com/datagrip/

Поддерживаемые СУБД
DataGrip — это универсальная IDE для работы с MySQL, PostgreSQL, Oracle, SQL Server, Sybase, DB2, SQLite, HyperSQL, Apache Derby и H2.

Работа с объектами БД и генерация кода.
DataGrip предоставляет инструменты для работы с объектами базы данных. Если вы создаёте или изменяете таблицу, добавляете или изменяете колонку, индекс, ключ в уже существующей, используйте графический интерфейс. Подобные изменения сопровождаются генерацией соответствующего скрипта: вы можете сразу выполнить сделанные изменения в базе или скопировать сгенерированный DDL-запрос в редактор и работать уже непосредственно с кодом.

Автодополнение.
DataGrip поддерживает автодополнение кода, что ускоряет написание запросов. Когда вы набираете код, IDE понимает контекст и делает работу за вас: не только помогает писать код, зная о ключевых словах и именах объектов БД, но и учитывает зависимости при написании JOIN, подсказывает тип параметров для выполнения фукнции, описывает струкруту таблицы в предложениях INSERT. Помимо этого, мы добавили шаблоны (Live Templates) для написания однотипного кода, а вы можете создавать собственные.

Поиск по коду и переименование.
IDE понимает, какие объекты базы вы используете в коде: если переименовать объект в запросе, то же случится и в базе. Переименуйте переменную или алиас в одном месте: это произойдёт во всём скрипте.

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

А если в запросе использовано имя объекта, которого нет в базе, например, ошиблись с названием столбца или таблицы, IDE сообщит о проблеме и предложит возможные решения.

Работа с данными.
Табличный редактор в DataGrip может фильтровать данные. Записывается условие в поле Filter criteria, как в предложении WHERE и увидите то, что вам нужно. Текстовый поиск по таблице тоже умеет фильтровать — удобно, если ищете данные, а колонку забыли. Есть навигация по данным — при наличии связи по внешним ключам можно попадать в те строчки таблиц, которые ссылаются на эти по foreign key, и наоборот.

Выполнение запросов.
Выбирайте, что IDE должна запускать, если курсор стоит на вложенном запросе: внутренний, внешний или все запросы скрипта. Для выполнения части запроса выделите код и запустите его. Анализируйте план выполнения запроса для оптимизации. В окне результата запроса доступны многие функции Table Editor, например он позволяет изменять данные и в нём работает текстовый поиск. Сравнивайте два результата в смежных окнах.

DataGrip — IDE на базе платформы IntelliJ, а значит в ней есть:

  • Мощный текстовый редактор с мультикурсорами и синтаксическое выделение кода.
  • Интеграция с системами контроля версий: Git, Subversion, и т. д.
  • Плагины: Terminal, Textmate bundles, и т. д.

Для проектов с открытым исходным кодом компания предоставляет бесплатную версию IDE: https://www.jetbrains.com/buy/opensource/?product=datagrip

>>> Подробности



Проверено: maxcom ()
Последнее исправление: Psych218 (всего исправлений: 6)

Ответ на: комментарий от stevejobs

хранимки были бы отличной штукой, если бы
работали бы со стандартным окружением

бугага, в MS SQL Server есть поддержка CLR, там можно такое делать

instant
()

Древовидное отображение структуры БД - порочная хрень, передираемая всеми у всех и дающая одинаково ублюдочный результат. :( Почему у разрабов нехватает кальция ударить яйцами по столу и сказать «Это неправильно!»?
В базе для рядового прогера есть три сущности - таблицы, вьюхи, хранимки. Причём последние сильно опциональны. Вот для этих вещей дерево - пушка для воробьёв, простых списков более, чем достаточно.
Тёмная тема IDE - тоже какой-то гиковский закидон, малолетние дебилы никак не вштыривают в здоровье зрения. Даже для фотошопов это сомнительная юзабилити (причём многие даже не в курсе, почему тёмные рамки), не говоря об обычных средах по работе с однообразными данными.
Вижу единственную киллерфичу - VCS. Интересно, умеет ли среда откатывать изменения? Одно дело - тупо залить в VCS свой DDL, другое - правильно откатиться с сохранением данных. Иногда ОЧЕНЬ БОЛЬШИХ данных (т.е. исключаем хитро*опый backup).

matumba ★★★★★
()
Ответ на: комментарий от Xellos

А ещё ORM у каждого свой велосипедный

В принципе у них много общего и даже есть попытки что-то стандартизовать на отдельных платформах (JPA).

а SQL один, и его знают все.

Только на самом примитивном уровне. Даже CREATE TABLE у каждой базы с нюансами, а уж про всякие рекурсивные запросы и дальше и не говорю.

Причём ценность SQL в скорости. А как раз для того, чтобы база быстро выполнила запрос — её надо очень хорошо знать, и тут ни о какой переносимости запросов речь не идёт, запрос может тюниться даже под конкретную версию БД.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от matumba

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

Ну дерево в данном случае и есть категоризированный набор списков. Что в нём плохого? Ты хочешь все сущности свалить в один большой список? Можно и так, но лучше разделить.

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

Поставь светлую или сделай свою. Тоже мне проблему нашёл.

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

Вижу единственную киллерфичу - VCS. Интересно, умеет ли среда откатывать изменения? Одно дело - тупо залить в VCS свой DDL, другое - правильно откатиться с сохранением данных. Иногда ОЧЕНЬ БОЛЬШИХ данных (т.е. исключаем хитро*опый backup).

Нет, конечно. Как ты себе это представляешь? Хочешь откатываться — используй транзакции или делай бэкапы.

Legioner ★★★★★
()
Ответ на: комментарий от matumba

правильно откатиться с сохранением данных

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

winlook38 ★★
()
Ответ на: комментарий от Legioner

ценность SQL в скорости

В понятности. Я не видел ни одной задачи, ограничивающейся CRUD. Всегда нужна хоть какая-то, но аналитика, отчётность. Чуть-чуть нетривиальную (не предусмотренную разработчиком ORM-а) аналитику на ORMах делать - гуглить, материться, гуглить, материться, гуглить, вытаскивать голый dbh, писать на sql и вздыхать с облегчением.

Xellos ★★★★★
()
Ответ на: комментарий от Xellos

Например в Hibernate есть HQL, там можно писать запросы до какой-то сложности.

Ну и, повторюсь, ничего (кроме религии) не мешает использовать SQL вместе с ORM.

Legioner ★★★★★
()

Исправил новость, добавив более подробное описание из припозднившейся новости от orionit, за что ему большая благодарность.

Klymedy ★★★★★
()
Ответ на: комментарий от Xellos

Можно не согласится, всегда есть кейсы в которых без орм никак. Например большое CRUD приложение со сложными бизнес правилами, человек открывает окно вдет сразу всю связанную информацию по одному бизнес контексту, т.к. на одно окно данные идут из 3,4,5... таблиц, кликает на кнопочку, ему еще одно окошко со связанными сущностями. В этом случае на raw sql получится, что на каждое представление нужно писать отдельный sql (мы же не хотим убить базу индивидуальными запросами на каждую таблицу), иногда sql будет большим, иногда очень большим, плюс еще отдельный sql на обновление данных. Выходит на 30 окон нужно будет 60 sql. Меняем в базе DDL -> ревьювим все sql. Тестируем все возможные окна на падения от ошибок в runtime. Есть этому альтернатива - тесты, минимум 60 тестов на 60 sql, но в реальности тестов будет больше из-за бизнес логики в условиях. Кстати сложный SQL для другого разработчика выглядит что-то вроде блоба, т.к. зачастую легче написать новый sql если знаешь бизнес правила, чем понять что делает уже написанный sql. Бизенс логика скорее всего перекочует в DAO и SQL, кто будет заморачиваться отображением объектов в модель предметной области когда используется сырой SQL? Просто это намного легче сделать, чем мучатся с самописным пулом объектов и заниматься отображением. В итоге поддержкой такого DAO нужно будет заниматься постоянно, изменения в бизнес правилах скорее всего потребуют изменения sql и как следствия тестов. Потому легче сразу использовать ORM, т.к. сразу из коробки получаешь отображение предметной области, т.е. вытаскиваешь не строчки из таблицы, а связные сущности, которые уже покрываешь тестами. И в этом случае переложение будет более организованно, с простым слоем DAO и отдельным слоем бизнес логики. Но серебренных пуль не бывает, потому конечно на всякие corner cases появляются и чистый SQL.

anonymous
()
Ответ на: комментарий от WatchCat

Та же JPA вполне себе позволяет и native запросы

ЖПА и в Африке ЖПА :-)

anonymous
()
Ответ на: комментарий от Legioner

Ну дерево в данном случае и есть категоризированный набор списков. Что в нём плохого?

В нём ВСЁ плохо. Когда в пылу работы ты бегаешь по сотне таблиц, ты УДОЛБАЕШЬСЯ бегать по дереву! (и не дай бог, кликнул куда-то во вьюшки - дерево бестолково распахивается и опять искать позицию)
Есть элементарные тэбы - встал в таблицы и визуально никакого мусора на экране - просто список названий.

Поставь светлую или сделай свою. Тоже мне проблему нашёл.

Небезызвестный Шерлок Холмс пользовался мелочами вовсю и что-то мне говорит, что не от великой квалификации задроты мастерят тёмные темы.
Терминал - это времянка со скроллингом, набрал команду - закрыл. Данные же висят перед глазами постоянно и корёжить глаза ради гиковских тем не вижу смысла.

Интересно, умеет ли среда откатывать изменения?

Нет, конечно. Как ты себе это представляешь?

Так же, как это делает нотепад: ты вставил строку, значит откат - вырезание строки. Придётся, конечно, анализировать DDL, но на то инструменты и существуют, чтобы облегчать жизнь!

matumba ★★★★★
()
Ответ на: комментарий от Rastafarra

В двух словах: писать тесты

anonymous
()
Ответ на: комментарий от anonymous

В первой половине опуса описан отличный процесс разработки. В результате получается тот же простой DAO слой из 60 SQL (~15 классов) покрытый тестами (60*2.5 в среднем), и ими же документированный. Если это CRUD, то SQL там элементарный, и сложностей чтения вызвать не должен. Не вижу причин переходить к ORM и бороться с его спецификой.

anonymous
()
Ответ на: комментарий от Legioner

Мне вот кеш мешает. А также призывы тимлида «Использовать одну технологию», чтобы не запутаться.

anonymous
()
Ответ на: комментарий от anonymous

Мне вот кеш мешает.

Он же автоматом сбрасывается при использовании SQL.

А также призывы тимлида «Использовать одну технологию», чтобы не запутаться.

Призывы тимлида это не объективный фактор :)

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

есть база в 3 тб, в ней картинки, дуртикни, схемы, карты, документы.

У тебя есть гуй, который дёргает что либо из этого и вместе. Например тебе нужна карта деревни шабашево, схема проезда, документы на строительство и договор подряда. Ты это дёргаешь через гуй. На сколько сильно будет различаться запрос в зависимости от базы?

erzented
()
Ответ на: комментарий от BaBL

Если у вас есть phpStrom, то весь функционал DataGrip там тоже есть.

moscas
()
Ответ на: комментарий от Legioner

В DataGrip можно попробовать следующее: выбрать две сехмы и в контекстном меню выбрать «Compare». Там есть и генерация миграционного скрипта.

moscas
()
Ответ на: комментарий от d9d9

Вообще такого быть не должно, я про интроспекцию и SSH. Можете проверить в версии 1.0.1 и прислать мне скриншот, если всё то же?

moscas
()
Ответ на: комментарий от moscas

Вообще такого быть не должно, я про интроспекцию и SSH. Можете проверить в версии 1.0.1 и прислать мне скриншот, если всё то же?

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

d9d9 ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.