LINUX.ORG.RU

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

 , , ,


0

1

Сижу на работе sql'щиком. Хотя я сам язычком sql ни разу не знаком, хз зачем меня скуэльщиком поставили. Сказали что мы переносим базу из мускула на постгресс. И на винде мне поставили крякнутую версию SQL Manager for PostgreSQL. Вообще чудовищная программа в плане перегруженности интерфейса. Вы когда-нибудь работали над этим клиентом? Задолбался я с этим sql'ем. Как на нем писать даже не знаю. Заманили меня что ты будешь с питоном работать, а на деле оказывается я буду обычным sql'щиком. Короче стоит ли бросить такую работу а мужики? Офис такая... Средненькая. А зп 30 тыс. рублей. Характер работы от 08 до 18 вечера сидишь как еб*утый и уходишь. Сказали возьми вот ту книгу «SQL справочник, Кевин Кляйн» к себе домой и будешь читать. Может все таки найти удаленку а? Как вы думаете уважаемые господа?

Deleted

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let you proof it

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

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

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

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

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

Let you proof it

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

select id from t where c;
...
foreach (i in ids) { update t set f=v where id = $i; }
даже вспоминать не стоит. Прям вэб-скейл получается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)