Задолбался с SQL Manager for PostgreSQL. Кто-нибудь этот клиент юзает?

ТС, не забудь отписать, что решил. Такой накал драмы, интересен исход.

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

Если что, создавай тему, кастуй, если поставишь ubuntu 18.04 или воткнёшь в винду Docker, я тебе помогу.

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

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

В смысле? Я же его поддерживаю как-то.

После тебя туда придет такой же джун и перепишет все на го или что на тот момент будет в тренде

Да, пусть переписывает на чём нравится.

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

Ещё требовали учить язык plpgsql

Ахаха, да. Будут шлёпать логику на хранимках.

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

Ничего не понятно, конечно, но сдаётся мне, что это просто затяжное тестовое задание.

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

изучение процедурного SQL - необходимый этап в освоении работы с базами данных. Хотя и не первый.

изучение процедурного SQL - необходимый этап в освоении работы с базами данных.

Да. Необходим чтобы сделать и потом так _никогда_ не делать.

Не морочьте людям голову.

у1Процедуры бывает можно заменить например дополнительной логикой в аызывающей программе. Но это может привести к неэффективной работе на сервере.

Процедурный SQL бывает можно заменить на другой язык. Например, в PostgreSQL хранимые процедуры можно писать на Python и других языках. Но это целессобразно только если нужна какая-то библиотека, доступная в Python-е, а не для того, чтобы откосить от изучения процедурного SQL. Общее правило - делать на нём то, что возможно, а на других языках - то, что на нём нельзя.

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

Например, в PostgreSQL хранимые процедуры можно писать на Python

А можно делать трехзвенку и не ломать никому мозг.

А чем хранимка отличается от кода приложения?

Тем, что это какой-нибудь pl/pgsql и что оно прибито болтами к конкретной субд, а в запущенных случаях еще и к версии субд. Для двухзвенщиков в аду будет отдельная контора где они будут мейнтейнить все то дерьмо, что писалось в российских госшарагах и банках.

Общее правило - делать на нём то, что возможно

Да да. А возможно на нём делать практически всё.

чтобы откосить

А когда это вложенки стали какой-то обязанностью типа службы в армии?

Кажется, понял. Ты считаешь хранимкой код на диалектах plsql, да? С какой там версии oracle можно хранимки на java лабать? Насчёт отличия: оно только в размещении кода: СБД vs СП, всё остальное идентично

а в запущенных случаях еще и к версии субд

Let you proof it

С какой там версии oracle можно хранимки на java лабать?

Ни с какой. Это плохая идея - тащить яву в субд. А лабать можно было и на mysql еще лет 5 назад через какие-то плагины.

всё остальное идентично

Кроме того, что приложение не масштабируется и жрёт ресурсы сервака с бд. Ах да, еще твоя субд начинает пытаться брать на себя все функции ОС.

Let you proof it

Как будем перекатываться на 12 ракл, так пруфану. (если вообще будем).

приложение не масштабируется и жрёт ресурсы сервака с бд

И как же вынос части кода с СБД способствует «масштабируемости»?

Как будем перекатываться на 12 ракл, так пруфану

Об отсутствии проблем совместимости plsql-я, надо полагать. С чего тогда заявления про завязки на версии БД, если премеров ещё не было?

И как же вынос части кода с СБД способствует «масштабируемости»?

Наверное тем, что он делает свои дела на отдельных хостах и никому при этом не мешает.

Об отсутствии проблем совместимости plsql-я, надо полагать.

Не имею желания спорить о вопросах веры.

Любители размазать бизнес логику по всех щелям прибыли. А теперь минусы:

1) Девелоперы помимо запросов в слое DAO должны еще знать что там на сервере на самом деле происходит, дебагинг и написание доп. функционала таких монстров становится очень времязатратным.

2) Хранимые процедуры выпадают из version control. Депоймент усложняется, хранимые процедуры и прочие изменения в базе находятся в отдельном проекте, вместе со всеми скрипратми иницализации/развертывания базы.

3) Юнит тесты, бывает даже треш в виде юнит тестов на PL/SQL. А как еще? Или тесты вынесем в отдельный проект? Надеюсь у вас есть корпоративная wiki где все это описано, и постоянно актуализируется, а не передается из уст в уста, т.к. легко такие сакральные знания потерять.

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

он делает свои дела на отдельных хостах

Особенно в типичной конфигуации, где перед БД стоит ровно _один_ хост. Про (как правило) сопутствующие ручные джоины(последовательным перебором) и долбёжку базы вида

select id from t where c;
...
foreach (i in ids) { update t set f=v where id = $i; }

Не имею желания спорить о вопросах веры

Но тем не менее ты начал о них спорить. Лол

Особенно в типичной конфигуации, где перед БД стоит ровно _один_ хост. ... даже вспоминать не стоит. Прям вэб-скейл получается.

Сам придумал, сам обиделся. Критические дни?

А вот и светочи разработки с первого курса! Давай уже, выдай хоть что-то конкретное. Хотя бы что такое критические дни(ты ведь этого не знаешь, не так ли?)

Хотя бы что такое критические дни(ты ведь этого не знаешь)

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

Это вот эти чтоле?

Хранимые процедуры выпадают из version control

Извини, но дальше даже желания читать не возникает. Неудивительно, что вы не осилили хранимки. Лол

Домой приду, отвечу, никуда не уходи.

Извини, но дальше даже желания читать не возникает. Неудивительно, что вы не осилили хранимки. Лол

Просто лол, тебе придется blame вызывать в нескольких проектах чтоб отслеживать изменения и выяснить в рамках какого бага он были сделанны. А если мы говорим про PL/SQL (не знаю как с другими нативными языками) то у тебя будет просто множество sql файлов в которых будут декларироваться хранимые процедуры полностью, каждая новая версия будет замещать предыдущую, тебе нужно будет брать последнюю и использовать diff/meld если нужно понять что поменялось. И все это из-за того что на базу изменения должны накатываться инкрементально, а теперь расскажи как вы преодолели эту проблему, вдруг действительно есть хорошая практика, а я не знаю.

будет просто множество sql файлов в которых будут декларироваться хранимые процедуры полностью, каждая новая версия будет замещать предыдущую, тебе нужно будет брать последнюю и использовать diff/meld если нужно понять что поменялось

Я так понял, с исходниками питона или, там, явы, ситуация принципиально отличается. А то в .py функция тоже полностью декларируется и

каждая новая версия будет замещать предыдущую, тебе нужно будет брать последнюю и использовать diff/meld если нужно понять что поменялось

Правильно ли я понимаю, что альтеры к базе применяются отдельно от хранимых процедур? Первые применяются инкрементально, вторы хранятся под системой контроля версий (в отдельном проекте?), и есть сложности с откатом изменений. В случае сложных изменений будет необходимо выкатывать последовательно альтеры к таблицам и прочий ddl, затем выкатываются хранимые процедуры и только затем новая версия приложения?

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

Ах вот ты о чём. Да, для обновления схемы/дистрибутивного наполнения БД есть отдельная сущность - upgrader. Только я не понимаю, что мешает скрипты этого upgrader-а хранить в vcs(в том же проекте, нах отдельный нужен). Про развертывание и порядок - это один возможных сценариев(всё зависит от конкретной БД/протоколов работы/допустимости downtime и пр.). Схема с ХП ничем не отличается от аналогов - везде есть alter-ы на данные и простая замена stateless сущностей(ХП это или функции в коде приложения)

Либо я уже видел тред с таким же содержанием но N лет назад, и сейчас снова тот же тролль по приколу решил ЭТО снова запостить, либо у меня реально дежавю.

И как же вынос части кода с СБД способствует «масштабируемости»?

Можно читать из сотен реплик.

Хранимые процедуры выпадают из version control

Каким образом?

DBA за 30к?
что за деревня?
в любом случае, плюнь этому человеку в лицо, который столько платит

Но тем не менее ты начал о них спорить.

Так это ты фанатично уверен, что принципиально нельзя навалить кода который будет работать только в одно версии субд и требуешь каких-то пруфов здесь и сейчас.

Особенно в типичной конфигуации, где перед БД стоит ровно _один_ хост.

Ну если всю жизнь пишешь на pl/sql - delphi, то да. Один хост и говноorm.

crutch_master> оно прибито болтами к конкретной субд, а в запущенных случаях еще и к версии субд anonymous> proof crutch_master> Так это ты фанатично уверен, что принципиально нельзя навалить кода который будет работать только в одно версии субд и требуешь каких-то пруфов здесь и сейчас Да неужели. Впрочем, вполне ожидаемо

не осилили хранимки

Наделали говна и радуются чему-то. Странные люди. Любая трёхзвенка умеет тоже самое делать что и ваши вонючие хранимки, только с нормальным ЯП вместо pl/pgsql и без необходимости наблюдать за результатами потуг разрабов, которые хотят сделать из своих субд ОС, попутно засунув туда целую галактику.

Неясно только, как ты умудрился одно с другим связать. Это и есть обещанный ответ, или ты домой ещё не добрался?

с нормальным ЯП вместо pl/pgsql
хотят сделать из своих субд ОС

А ты совсем необучаемый. Банан хочешь?

3) Юнит тесты, бывает даже треш в виде юнит тестов на PL/SQL. А как еще?

А как это говно тестить, когда все читаю всё и пишут во всё дёргая по ходу кучу триггеров, которые дёргают еще кучу чего. А никак. У нас тестят прямо на проде.

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

Так это дефотлная двухзвенка всея СНГ. Людям тяжело думать дальше привычных шаблонов.

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

Удачи отдебажить запрос с 3+ подзапросами. Через месяц после его написания пол дня только в его смысл въезжать будешь. Если умники еще напихали дерьма в триггеры сложнее ++ключа - вообще закапывай.

Я думал ты умеешь в агрументы, а ты совсем скучный.

Ты там бухой чтоле? Или для разнообпазия решил меня поддержать?

Да, для обновления схемы/дистрибутивного наполнения БД есть отдельная сущность - upgrader.

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

Ты plsql-анон всё-в-субд? Чем я тебя поддержал?

Ты там бухой чтоле?

Что сразу бухой? Я давно не холиварил!

Перечитай ветку, болезный

Мне бы хотелось бы услышать хорошие практики

Их нет. Там всё может зависить друг от друга и разруливается это только ручками. Одно неверное движение, апдейт похерен и сам уже не накатится. У нас вообще никто даже не заморачивался на vcs да и толком не знают зачем это нужно.

Перечитал, не понял, что тебе не понятно.

Там всех в этой придётся опплёвывать.