UPSERT и не только. Что ждать от PostgreSQL 9.5?

надо тыкать в pgsql и декартовы прозведения с теориями множеств

Думаю многие потыкавшись в баги pgadmin забивают на эту базу данных даже не добравшись толком до неё.

Чёрт! Через 7 лет использования постгреса я узнал, что кроме psql бывает ещё и вебморда! Собсна, нафига она была бы мне нужна...

Держись за кресло покрепче. pgadmin - это _не_ вебморда!

Держись за кресло покрепче. pgadmin - это _не_ вебморда!

всё равно не понимаю зачем мне что то кроме psql, превосходнейший клиент! учитывая, что закалялся я в sql*plus...

но автотюнинг актуален все-же

согласен. было бы неплохо.

кроме psql бывает ещё и вебморда!

Какая еще к лешему веб-морда. Я про приложение pgadmin. Что-то в стиле «sql server management studio». psql это надо быть слишком задротом и не ценить свое время.

Естественно пробовал. Более чем рабочая схема, особенно когда нужны поиски по множеству атрибутов, которые заранее неизвестны.

ФС можно рассматривать как некоторую СУБД, спору нет.

ФС можно рассматривать как «движок» хранения данных, а не СУБД. ОС можно рассматривать как СУБД.

при чём тут постгрес?

Постгрес - это частный случай ОС :-)

У постгреса есть большая проблема на мой взгляд - бесплатные средства для работы с ней еще та галиматья.

А что, если купить качественный инструмент?

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

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

И почему EAV более «реляционна» чем создание таблицы или хранение структурированного blob? С blob понятно, они находятся примерно в одной категории, можно поспорить, кто «реляционее». Но с обычной таблицей?..

Это с одной стороны, а с другой, у тебя даже 1нф не выполняется.

Как это — не выполняется? Еще как выполняется! Блоб с точки зрения РБД — атомарен. Я даже спорить по данному вопросу не собираюсь ввиду бесперспективности, т.к. мы просто упрёмся в аналог дисциплины спецолимпиады как моделировать ФИО:«Иванов Иван Иванович» или («Иванов», «Иван», «Иванович») или («Иванов», «Иван Иванович»).

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

Кстати, решение «динамическая таблица на сигнал» — вообще антиидиома. Как и таблица «атрибуты документов». Но да, применяется широко.

А зачем нужен pgadmin, если есть psql?

Из GUI мне лично очень понравился плагин Database из IntelliJ IDEA (есть в виде отдельного продукта 0xdbe).

Естественно пробовал

т.е. объёмы были смешные и производительность не волновала. да, так это будет вполне работать.

Что задротского в psql? Ладно, секретарши не осилили SQL, для которых он создавался, но сегодня уже что, программисты, работающие с БД, не осиливают SQL?

Чего конкретно не хватает в psql? Я могу представить себе только автодополнение имён таблиц и столбцов. Но во всяких mysqladmin этого тоже нет. Там такое же текстовое окошко для ввода SQL.

psql это надо быть слишком задротом

ПНХ. я ценю своё время, у меня всё получается в psql.

кстати toad для слона не помешал бы

ФС можно рассматривать как «движок» хранения данных, а не СУБД. ОС можно рассматривать как СУБД.

Всё можно рассматривать движком хранения данных. a[0] = «блабла» — тоже движок хранения данных. А вот что такое ОС стоит всё-таки ознакмиться с формальными определениями, а не выдумывать самостоятельно.

P.S. и чего блин капча злая сегодня? уйду нафиг отсюда.

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

Что задротского в psql?

И действительно, что задротского в лысой командной строке. Даже не знаю что сказать... Ну наверно всё!

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

Постргрес не нужнен, потому что есть Постгрес. :-)

C++0X появился только для того, чтобы умные люди перестали писать на C и перешли на Постгрес.

Цепепе-ноль-икс - это такой мощный язык, что Постгрес не нужен :-)

И действительно, что задротского в лысой командной строке. Даже не знаю что сказать... Ну наверно всё!

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

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

Первое, что я делаю в IDE это отключаю попугайскую расцветку. Потому что отвлекает. И знаю многих, кто делает то же самое. Это так, абстрактно.

Миллионы SQL-запросов прекрасно хранятся в файлах. В psql можно загрузить запрос из файла, можно его передать в vim для редактирования (который тебе подсветит всё, что угодно), уж выполнить запрос-то и подавно можно.

Там есть автодополнение по табу

Первое, что я делаю в IDE это отключаю попугайскую расцветку. Потому что отвлекает.

Твой аватар попугайский и отвлекает. Отключай.

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

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

Чего конкретно не хватает в psql?

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

Там такое же текстовое окошко для ввода SQL.

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

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

Синтаксис SQL это для каких-нибудь кобольщиков. Нормальный человек чем реже его видит тем лучше себя чувствует.

Синтаксис SQL это для каких-нибудь кобольщиков. Нормальный человек чем реже его видит тем лучше себя чувствует.

Нормальному человеку синтаксис вообще до фонаря.

Но во всяких mysqladmin этого тоже нет.

Есть.

И даже внутри текстового литерала в функции на plpython?

Странно ждать дополнения в PL/Python от клтиента MySQL, не находите?

Странно обсуждать клиент MySQL в теме о postgres, не так ли?

даже небо, даже аллах!

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

И не менее странно задавать вопрос той, кто не начинал это обсуждение ;-)

Раз не ты начинала, значит участие в обсуждении не считается. Логично.

у 7 нянек, ну, дальше Вы знаете для 1С 4 специалиста. ню-ню

Кроме элиты MSSQL что-то нужно ещё лол?

нет. для типовых задач амно-сайтов - мускул на самом деле попроще.

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

Мне не нужно «часто проверять», мне нужно показать пользователю (оператору АРМ) обычный CRUD: списки заказов, пользователей, звонков в колл-центр и т.п. Естественно, мне нужно показывать сколько в системе тех же пользователей. Что тут не так-то?

Тормозить оно начинает уже от 100 тысяч записей, апгрейдом железа и покупкой provisioned IOPS на амазоне можно добиться относительно приемлимой работы на 500-800 тысячах, но в любом случае это неприемлемо. Сейчас у меня в проекте сущности, которых уже 40 миллионов, и их опять нужно показывать с поиском, фильтрацией и указанием количества результатов. Поиск и фильтрация по индексам работают идеально, а вот количество результатов считается минутами.

Я, конечно, прикостылил обёртывание запросов в SELECT COUNT(*) FROM ($query LIMIT 10000) и добавил парсер EXPLAIN ANALYZE, но не знаю как без матов прокомментировать такое «решение».

А зачем пользователю знать, сколько миллионов строк в результате? Показать кнопку «дальше» и всё. Как показать кнопку «дальше» и как эффективно найти следующую страничку, думаю, и так понятно.

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

MariaDB это то же самое, что и MySQL.

Лол.

назовешь 10 отличий и свободен

Тормозить оно начинает уже от 100 тысяч записей

ни одна база данных не способна противостоять идиотам - они всегда побеждали и будут побеждать. аминь...

Погоди, у тебя количество пользователей получается запросом select count(*) from tablename;?

а как надо делать в таком случае?

Я, конечно, прикостылил обёртывание запросов в SELECT COUNT(*) FROM ($query LIMIT 10000) и добавил парсер EXPLAIN ANALYZE, но не знаю как без матов прокомментировать такое «решение».

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

есть документ со 100500 полями, который никогда не меняется, а для его визуализации нужна львиная доля данных. Что будет более «реляционно»: создавать кортеж размером 100500 или сделать отдельные поля для индексов, а остальное засунуть в блоб/композитный тип/JSON?

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

судя по подходу
если задача не решается влоб?

В тебе пропадает бюрократ, всеми силами цепляющийся за необходимость существования запретов там, где требуется простое как гвоздь решение, и считает само собой очевидным, что нужно набрать 10 справок на разных концах города. В лоб же не решается, нужен «подход»!

Не смешно ли, когда для подсчета количества результатов нужно потратить больше человеко-часов, чем для разработки всего проекта?

Если база данных даже не может простым способом посчитать количество хранящихся в себе данных, то такая база данных не нужна. Абсолютно насрать на транзакции. Пусть оно хотя бы в автокоммит режиме быстро работает.

А зачем пользователю знать, сколько миллионов строк в результате?
Показать кнопку «дальше» и всё.

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

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

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

Я поражаюсь вашему желанию оправдывать говно.

бюрократ, всеми силами цепляющийся за необходимость существования запретов

Ну, тут как сказать. Есть такая бюрократия, польза которой очевидна. Но такие случаи относительно редки. Условно скажем, ядерная энергетика. Или в военной сфере. Есть нормативы, нарушение которых приводит к гибели людей. Такие нормы, понятно, будут соблюдаться пунктуально. В современных условиях значительная часть бюрократий легко идёт на нарушение таких норм, которые нарушать нельзя, даже законодательные нормы нарушаются. Выдумывая при этом свои собственные «низ-зя» для оправдания своего существования

Абсолютно насрать на транзакции.

Software development practices уровня ЛОРа.