Postgres Professional обновила бесплатный курс по администрированию PostgreSQL 16

У них есть возможность бесплатно сдать онлайн-экзамен по этому курсу и бесплатно получить сертификат о прохождении? Если есть, то можно даже пройти)

У меня вот в БД нужд нет, но когда я вижу что-то про Postgres такое ощущение что это не БД, а операционная система. Я просто в виду отсутствия личной необходимости не тыкал прям уж так. Но оно реально само по себе такое всё огромное и не знаю как выразиться «наукоёмкое» или у меня всё же ложное впечатление, ну типа да сущность большая, но не настолько?

Ничего не мешает изучать его «от простого к сложному», разве нет?

когда я вижу что-то про Postgres такое ощущение что это не БД, а операционная система

Ты не поверишь… (%

Да так можно про что угодно сказать :) Ну да ладно, у меня так, праздный интерес

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

При этом, его можно просто поставить, настроить доступ, прочитав примерно абзац, или, даже, комментарии в конфигурационном файле, и постгрес начинает «просто работать». А вот если хочется репликации, тюнинга, шардинга и всего прочего, то да, надо читать, как это делается.

Ровно то же самое и с другими СУБД. :)

«наукоёмкое»

Очень точное определение!

но когда я вижу что-то про Postgres такое ощущение что это не БД, а операционная система

Ты наверное, ещё с ORACLE Database не сталкивался… 😊

P.S. И если расчехлить занудство, то это действительно не БД. А СУБД. 😊

По умолчанию PostgreSQL сконфигурирован таким образом, чтобы он мог быть запущен практически на любом компьютере и не слишком мешал при этом работе других приложений. Это особенно касается используемой памяти. Настройки по умолчанию подходят только для следующего использования: с ними вы сможете проверить, работает ли установка PostgreSQL, создать тестовую базу уровня записной книжки и потренироваться писать к ней запросы. Если вы собираетесь разрабатывать (а тем более запускать в работу) реальные приложения, то настройки придётся радикально изменить.

А. Ю. Васильев «Работа с PostgreSQL: настройка и масштабирование»

Такое же ощущение.

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

3К, и только очно.

Для личного использования есть SQLite. Это то, что заменяет текстовые файлы и Excel.

Если у вас 1000 строк в таблице то SQL уже на порядок облегчает работу с ней. А уж SQLite c консольной утилитой вообще подарок.

ну типа да сущность большая, но не настолько?

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

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

БазаДанных это по сути уже готовый сайт

Какая интересная версия. :))

Но, вообще-то говоря, БД и сайт могут и не «пересекаться» в жизни... ;)

Какая интересная версия. :))

Это практика простыми словами. Бизнесу нужен сайт для учёта чего либо, а это записывать куда-то изменения, потом читать записанное и получать статистику. Важно чтоб изменнения правильно записывались, записи не терялись.

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

https://postgrespro.ru/education/books

Кстати книги изумительные на сайте у PostgresPro. Все по полочкам, есть два варианта демострационной базы данных.

Начиная от математической теории отношений когда таблица-отношение, строка-котреж, колонка-атрибут. И дальше в практику. Рекомендую.

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

Ну и я примерно о том же. Насчет «радикально»... Ну, наверное. Мне продакшн как-то настраивать не доводилось. Я как-то не DBA. Для разработки да, добавлял расширения типа того же TimeScale. Но оно само под себя конфиги тюнит.

Мне в начале не хватало нескольких теизисов:

1. SQL декларативен, пишем что надо, а не как.
2. Выражения SQL это таблицы, таблица на входе, на выходе она же.
3. Joins это декартово произведение всех строк со всеми, с последющией фильтрацией в статье ON.

Дальше с этой основой уже легче разбираться.

Это практика простыми словами

Это плохая практика. :)

Бизнесу нужен сайт для учёта чего либо

Для «учёта чего либо» сайт не нужен. Для продаж учтённого — да, сгодится. :)

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

Это называется как-то вроде «системы складского учёта», с вариациями. А сайт тут по-прежнему «сбоку», и «для учёта чего либо» он не нужен совершенно.

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

Да, скорее всего, нехватка опыта. Я с ним, помнится, как-то сразу подружился... с периодическим подглядыванием в мануалы. :)

Да он и в продакшкне неплох, пока ты в него не пытаешься тысяч 10 записей запихнуть за короткое время. Он такое тоже умеет, только память жрет нещадно.

А это надо Дейта читать про всякие нормальные формы и реляционную алгебру.

Это плохая практика. :)

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

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

И DBMS беред на себя львинную долю монотонной рутинной работы.

Мне нравится книга Моргунова Основы Языка SQL или что-то в роде того тем, что там теории ровно столько, чтоб ее хватило для успешной практики. Плюс отличная идея с Демонстрационными базами данных.

https://postgrespro.ru/education/books/sqlprimer

Углубляться в теорию алгебр это интересно и приятно, но вторично. Точно также нормальные формы интуитвно понятны.

Ну хватило и хорошо. Это ж каждый свою книжку находит. Потребность в LEFT OUTER JOIN не сразу возникает. К тому же, читать просто книжку про SQL (равно как и любой другой язык) не особо помогает. От референса на SELECT только ослепнуть можно. Интересно читать какой-нибудь Cookbook для ответа на вопрос «а как мне сделать то-то и то-то». Ну а вот потом уже референс на SELECT, но уже выборочно. :)

Да-да... Из жизни: — Ты Оракл знаешь? -ДА! select * from all_tables :)

LEFT OUTER JOIN как раз хорошо объясняется житейской логикой: берем все строки левой таблицы и соединяем с правой по правилу. Если какая-то строка левой не вошла, заполняем колонки из правой NULL.

Фокус с алгебрами в том, что знать о их сущестовании на уровне одной двух страниц ой как помогает. А вот изучать их отвлекает от основной линии практики. Обычно либо том на 1000 страниц с алгебрами, либо cookbook с места в карьер. Самые ценные это книги по середине, где и теория объясняется и практика есть. И cookbook помогает когда основные теоретические тезисы хорошо изучены.

А какая боевая БД маленькая? Я серьёзно ни Microsoft SQL Server ни Oracle не ковырял, но вангую что там не меньше объёмы.

Это пустая дискуссия получается. Да, оно так. Опять же, у каждого своя практика. Я вот отвратительный прикладник. Мне приходилось писать четырехэтажные запросы, но без особого удовольствия. Я больше разграничением доступа и всяким row-level security занимался и писал расширения для постгреса вотпрям на С :)

Я вот отвратительный прикладник.

Вы знаете, я тоже утилитарист и практик. И тоже начинал SQL с Cookbook и Tutorials, c места в карьер. Но мне было не уютно с SQL, узнав теоретические основы буквально на несколько страниц, мне стало легко и приятно.

Это пустая дискуссия получается.

Дак они все по большому счёту пустые. Так почесать язык, поделиться впечатлениями.

Они только слайды обновили? Где обновленное видео?

Оракл сильно больше всех, а если туда же прибавить Oracle Applications, то вообще самодостаточный монстрик получается. MS-SQL — это купленный когда-то на корню Sybase. Ну хорошая база была прошлого века. Не сказать, что б монстрообразная. Как-то его развивают, сейчас примерно равен постгресу по наворотам. У постгреса больше языков для написания хранимых процедур, зачем оно — не ведаю. Но есть :)

Попробуйте листать быстрее, сэр

«Redis и MongoDB не нужны, потому что Постгрес проще, удобнее и быстрее. Если бы Ruby был написан на хранимках в Постгресе, он работал бы в три раза быстрее и не падал. Ноду пришлось писать на V8, потому что джава-скриптеры не поняли лицензию Постгреса, а Erlang появился, потому что кто-то просто не умеет пользоваться триггерами и хранимками. K&R после создания C пришлось писать UNIX, потому что они хотели, конечно, написать Постгрес, но ему было не на чем запускаться. C++ появился только для того, чтобы умные люди перестали писать на C и перешли на Постгрес. Разработка файловых систем нового поколения часто тормозится (особенно ZFS), потому что люди понимают, что с какой стороны не подходи и что не делай, а из-за требований нормальной транзакционности все равно получается Постгрес! Сам Постгрес написан на хранимках Постгреса, мейкфайл выполнен в виде дампа Постгреса, и собирается Постгрес Постгресом.»

:) (c) непомнюкто

Ехал постгрес через постгрес... :)

на корню Sybase. Ну хорошая база была прошлого века.

так МСSQL на 99% использовалась в 1с, сейчас же все активно переходят на пострес, который без оптимизаторов от сабжа тугой и тормозной из коробки и никак не настраивается при больших базах.

Так в нем еще и коннект дорогой. Вот и городят всяческие баунсеры и прочие внешние connection pools

Отличная СУБД, рад что мигрировал. Прям вот так вот и нужно делать

Сейчас «мигрируем» с MS-SQL на Постгрес... Лучше б мы этого не делали. Коннект дорогой шотриндец! Пот приходится городить коннекшн-пулы, баунсеры и вот это все... Никто ж сам руками запросы же не пишет, а связка постгрес+ какой-нибудь ORM... Вот тут и начинается падение производительности.

Пишите вьюхи, они тоже через орм и миграции работают

Не наш, немного, бизнес, — ORMы отлаживать. Как там какой-то виндовый ORM на дотнете с базой общается, да хтож его ведает-то? Надеюсь лучше, чем хваленый джавайский Hibernate, который чуть ли не вынимал из базы все и разбирал потом нужное кодом.

Нет, PostgreSQL лучше. SQLite я рассматриваю только как встройку в приложение, которое не на сервере крутится у админа, а у юзера который ни разу ни админ. Там ему и место. А у PostgreSQL и инструменты лучше, чем у SQLite и производительность выше. Единственное что с PostgreSQL плохо - очень дурная система логинов. Т.е. у тебя вот есть и юзеры самого PostgreSQL и системный юзер, от которого всё управляется. Почему нельзя было сделать в PostgreSQL независимых от ОС юзеров - загадка. Из-за этого в администрировании этой СУБД говно происходит, вроде оправданного sudo su. Короче да можно управлять пользователями и ролями там, но всё как-то через жопу и переусложнено на ровном месте.

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

Мне вот PostgreSQL (тот который обычный) нужен чтоб csv в него загружать и там его обрабатывать. Это сильно быстрее и гораздо меньше оперативки жрёт, чем теребонькать питон с pandas-ом. Разница прям на порядки.

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

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