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

ты хотел сказать при вызове? прикольный метод ))

У вас что, нет тестов на целостность и работоспособность базы до выкатывания в прод? А вы смелые!

Интересно, что там с интеллектом у сисадминов? :-)

А вот если бы умела? Как эти изменения потом на тест и дальше на прод выкатывать?

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

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

Ява там или не ява, ORM или SQL, JetBrains или FSF, это всё, конечно же, интересно. Но вот это:

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

это вызывает у меня баттхёрт. Как можно было вместо такого офигенного названия как «0XDBE» выбрать такой унылый отстой как «DataGrip»? Какой имбецил из отдела маркетинга сколько километров членов отсосал, чтобы пропихнуть эту унылую идею? Почему людям без фантазии вообще разрешают какие-то идеи предлагать? Чума на оба их дома!

Интересно, что там с интеллектом у сисадминов? :-)

Судя по тому коду, который приходится админить — похоже, что лучше, чем у среднего программиста. А судя по зарплате, так и точно лучше.

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

Так вот, работал в нескольких относительно больших (50+ человек офис) айтишных компаниях до этого - ни где ни кто и не думал покупать лицензии, ОСОБЕННО на IDE (про винду и фотошопы дизайнерам ни кто и не говорит - только с торрентов).

Правда и зарплата была в конвертах - за 8 лет активной работы веб-разработчиком официально трудоустроен не был ни разу.

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

Российский хостинг-провайдер и не конченая контора? Нет, такого даже в сказках не бывает.

Так вот, работал в нескольких относительно больших (50+ человек офис) айтишных компаниях до этого - ни где ни кто и не думал покупать лицензии, ОСОБЕННО на IDE (про винду и фотошопы дизайнерам ни кто и не говорит - только с торрентов).

Вся суть™ российского бизнеса. Ну и как, нравилось работать с ворами? Уж в каких гадюшниках ни приходилось по началу работать, но вопроса о покупке инструментов не возникало ни разу. Есть обоснованная необходимость? Значит есть и бюджет на её удовлетворение.

Как бы, пиратство - не воровство. Уже сто раз обмусолен этот вопрос. Если вкрадце, то идея одной картинкой: http://tightmixblog.com/wp-content/uploads/2011/03/piracy-not-theft-460x328.jpg

Лучше бы провели оптимизацию IDEA.

расскажи мне в двух словах как отследить все хранимки, которые отвалились потому что в табличке грохнули поле?

У оракли так

select * from dba_objects t where t.status = 'INVALID';

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

Согласен. Перефразирую: каково было работать с правовыми нигилистами?

Отлично, классные были коллективы.

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

Руководству главное чтоб продавалось.

Обычно туда всю бизнес-логику переносят. Так что размер «SQL запросиков» может быть сколь угодно большим.

Для кого обычно? Знаю человека, который гордился запросом в 15000 строк.

Тебе уже поздно обьяснять уже...Мозг уже в гавно у тебя превратился.

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

Это где инструменты на презентациях выбирают? В любом случае, можно 3518 говорить, кому надо, тот поймёт, а кто не поймёт, ему пофиг.

Рыбак рыбака.

Не существует такого. Все пишут миграции вручную.

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

Так посмотрите в сторону полностью бесплатного dbeaver. Он может все то же самое что и этот, но совершенно бесплатен.

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

Целевая аудитория продукта понимает. Подписывающая контракт на закупки рука не понимает ни того, ни другого. Унылые серые люди без фантазии правят бал. Горе нам!

Тебе уже поздно обьяснять уже...Мозг уже в гавно у тебя превратился.

Отличная демонстрация словарного запаса и «красоты» речи в двух смежных предложениях, между которых нет пробела, 2 ошибки и 2 повтора «тебе» и «уже» :-) Так что ты там про мозг заикнулся? :-)

Не существует такого. Все пишут миграции вручную.

Под питон и алхимию существует Alembic.

Слыш, анон! Ты заеб уже своими смайликами, которые как маркер тупых комментариев. Хватит гадить в каждую тему уже...

в базу бизнес-логику обычно переносят ламеры

Да, ты упорот... И как ниже написали, срешь дальше чем видишь.

хранимки были бы отличной штукой, если бы не писались на том убогом говне на каком обычно пишутся (а писались бы на Java или C# например), работали бы со стандартным окружением (любая версия Java/.NET по выбору + полная инфраструктура maven/nuget), хранились и версионировались бы прямо на файловой системе, и имели бы нормальную интеграцию с Eclipse,IDEA и Visual Studio

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

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

хранимки были бы отличной штукой, если бы не писались на том убогом говне на каком обычно пишутся (а писались бы на Java или C# например

Учись, студент http://www.postgresql.org/docs/9.4/static/external-pl.html :-)

PL/SQL Developer можно уже выкидывать?

В джанго миграции генерятся автоматически из коробки. Иногда их надо только немного подправлять и писать миграции данных.

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

Речь не про генерацию миграций по изменению в коде, речь вот об этом:

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

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

писались бы на Java или C# например
работали бы со стандартным окружением (любая версия Java/.NET по выбору + полная инфраструктура maven/nuget)

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

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

И вместо пары выполняющихся влет строк с применением window functions или встроенного OLAP, мы получаем тормозное бойлерплейтнутое говно из фабрик абстракций фабрик алгоритмов (плюс еще и с тормозной и бойлерплейтнутой арифметикой для денег в случае жабоговна).

Я, наверное, слишком длинную простыню написал и ты не дочитал, так что процитирую:

Для этого на уровне СУБД строится дополнительный слой из вьюх и хранимок и тут твой сисярп с нугетом нахер не сдались.

Так проблема как раз в том что в реальном мире применительно к тем же говнобизнесапликейшонам аналитика вроде

SELECT empno,
       deptno,
       sal,
       MIN(sal) KEEP (DENSE_RANK FIRST ORDER BY sal) OVER (PARTITION BY deptno) "Lowest",
       MAX(sal) KEEP (DENSE_RANK LAST ORDER BY sal) OVER (PARTITION BY deptno) "Highest"
FROM   emp
ORDER BY deptno, sal;

и составляют где-то 90% бизнес-логики. И при переносе на уровень приложения (createSQLQuery считаем читерством) превращаются в гигатонны тормозящего бойлерплейтнутого говна, которое в целом посвящено написани заново худшей версии OLAP-велосипеда с абстрактными фабриками. А говнокруд, под который ORM в целом и заточен, составляет лишь где-то 10% всей бизнеслогики.

1) в хайлоаде может быть все по-другому, воочию видел ускорение формирования отчета с 25 часов до 8 часов от перетаскивания в базу и переписывания кусков на чистом си

2) чтобы разбирать приложение на уровни, нужно эти уровни проектировать, заниматься архитектурой, вводить какую-то специальную дисциплину. Например, мы обычно юзаем для монолитных приложений устаревшую четырехуровневую архитектуру от оракла (c бд внизу и веб-интерфейсом вверху), и SOA паттерны для сервисов. Но это требует три четверти времени не решать задачу, а заниматься дисциплиной и планированием.

представим, что у нас заказчик, который из набора (дешево, быстро, качественно) расставил приоритеты так: быстро, дешево, качественно. То есть качество его не волнует вообще, но нужно нахерачить приложение побыстрее в одно рыло. И вот тут можно взять какой-нибудь тарантул и нахерачить все на LUA прямо на хранимках: http://habrahabr.ru/company/mailru/blog/272669/

Для кого обычно? Знаю человека, который гордился запросом в 15000 строк.

Ну такому человеку нужно дать какую-нибудь премию типа нобелевской или филдсовской и отправить в психушку.:) Но пару-тройку раз пришлось мне упереться в Informix-е в ограничение размера хранимок в 64К.

аналитика... 90%

Ага, только это даже не в 10% приложений из того самого реального мира.

говнокруд, под который ORM в целом и заточен

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

И при переносе на уровень приложения

Т.е. у тебя проблема с описанием бизнес-сущности в ОРМ-стиле и отражением ее в РСУБД через представление? Это решаемо. Пусть через костыли к ОРМу, но я не вижу проблемы, скажем, в добавлении к сущность имени представления, на основе которого будет происходить отображение в РСУБД. Это больше вопрос к архитекторам.

в хайлоаде

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

Но это требует три четверти времени не решать задачу, а заниматься дисциплиной и планированием.

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

тарантул и нахерачить все на LUA прямо на хранимках

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

1) в хайлоаде может быть все по-другому, воочию видел ускорение формирования отчета с 25 часов до 8 часов от перетаскивания в базу и переписывания кусков на чистом си

Да не обязательно на Си, был свидетелем того, как расчёт месячной зп на предприятие ускорили с 24-48 часов до 5-15 минут переписыванием pl/sql хранимки (хотя индексы забытые тоже небось были). Вот только нужно ли это? Бухгалтеры стали жаловаться, ведь потерялась видимость значимости их работы =)))

манипуляции с моделью данных происходят через промежуточный слой метаданных

Да, эта тема в ror, django и симфонии очень нравится, особенно на этапе создания схемы. Но когда проект ожил и надо вещи посложнее выполнять: индексы хитрые добавить, данные не потерять при удалении-создании полей, изменениях кратности связей, изменении типов — тут миграции на чистом SQL проще описать.

Хайлоад это другое

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

четверть проектировать и три четверти говнячить? Ты серьезно?

на позапрошлой работе мы не проектировали вообще. То есть вообще совсем нисколько, 0. И тестирования никакого не было. Зато компания поднимала очень некислые бабки, штат в 500 человек, все дела. Проектов пресс. Я собственно и свалил оттуда, потому что компании были не нужны архитекторы, там нечего делать. Но компания бабки все равно поднимает, т.е. успешна! Такие дела

Но когда проект ожил и надо вещи посложнее выполнять

У нас это все хранится в метаданных, но мы заточены на оракл, нам не нужно заботиться о переносимости между разными СУБД.

не проектировали вообще.
И тестирования никакого не было

Это возможно только для проектов, не нуждающихся в поддержке.

компания поднимала очень некислые бабки

Это возможно даже не разрабатывая ПО, но мы ведь тут говорим не о том, как не разрабатывать ПО.

А ещё ORM у каждого свой велосипедный, а SQL один, и его знают все.

Это возможно только для проектов, не нуждающихся в поддержке.

только если результат должен получиться качественным. А так как на качество насрать, можно для чего угодно :) Ну подумаешь, где-то что-то отвалилось и никто этого не заметил - будет новый контракт на фикс предыдущего фикса :)