LINUX.ORG.RU

PostgreSQL 9.2

 


1

2

Вышла новая версия СУБД PostgreSQL — 9.2.

Основные изменения в этой версии:

  • «Index Only Scans» — возможность выбирать данные прямо из индекса, если в индексе они есть. До этого СУБД использовала индекс только для поиска, непосредственно данные всегда выбирались из страниц данных. Данная функция работает только в случае если страница с искомыми данными не менялась с момента последней операции VACUUM.
  • Каскадная репликация — standby сервера теперь тоже могут отправлять журнал транзакций другим узлам.
  • Поддержка типа данных JSON для хранения неструктурированных документов.
  • Добавлены типы данных для диапазонов значений.
  • Серия различных оптимизаций производительности, в том числе:
    • улучшенная работа с блокировками на системах с 32-мя и более ядрами;
    • функция сортировки в памяти ускорена на 25% в некоторых случаях;
    • простаивающий узел СУБД теперь проявляет меньше активности, что полезно при работе в виртуальной машине или при применении в embedded окружении;
    • ускорена работа команды COPY за счет уменьшения операций записи в журнал транзакций и уменьшения количества блокировок;
    • добавлен сбор статистики для массивов, благодаря чему улучшена генерация планов исполнения для запросов с массивами.

>>> Подробности

★★★★★

Последнее исправление: maxcom (всего исправлений: 5)
Ответ на: комментарий от special-k

Собственно как и я не дождался примера необходимости валидации всех полей на уровне БД.

Никакой _необходимости_ нет, всё можно сделать в приложении. Точно так же нет никакой необходимости вообще использовать RDBMS - всё можно сделать в файлах. WAIT O SHI~... можно ведь и без файлов!!!11

tailgunner ★★★★★
()
Ответ на: комментарий от special-k

Я тебе повторяю: следить за лишними пятью багтрекерами и обновлять все твои либы по отдельности мне нафиг не упало.

//такое ощущение, что разговариваю с админом локалхоста

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

нет никакой необходимости вообще использовать RDBMS

Как минимум есть альтернативы :)

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

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

leave ★★★★★
()
Ответ на: комментарий от special-k

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

leave ★★★★★
()
Ответ на: комментарий от baka-kun

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

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

В том-то и дело, что и данные сохранит

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

Это задача человека: решить, как поступить с данными, которые не удовлетворяют вновь появившимся ограничениям.

Вижу, ты наконец начал улавливать суть. Молодец.

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

Точно так же нет никакой необходимости вообще использовать RDBMS - всё можно сделать в файлах.

Проверка на больше/меньше это не основная фича RDBMS. И юзают их не для этого.

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

Проверка на больше/меньше это не основная фича RDBMS

Спасибо, Кэп. А вот проверка ограничений целостности - одна из основных.

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

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

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

Да хорош тормозить.

Я так и не услышал, чем помешает или усложнит. Можно с примерами.

без дополнительных хранимых процедур

А они-то тут при чем?

Тебе нужна какая-то абстрактная «целостность данных».

Ох ты ж, LOL твою мать! Щас, проржусь… :D

baka-kun ★★★★★
()
Ответ на: комментарий от tailgunner

А вот проверка ограничений целостности - одна из основных.

От внешних ключей никто и не собирается отказываться.

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

От внешних ключей никто и не собирается отказываться.

А почему? %) А от NOT NULL, UNIQUE? А от CHECK совсем отказались или только от проверки диапазонов?

tailgunner ★★★★★
()
Ответ на: комментарий от baka-kun

«схема БД»

http://guides.rubyonrails.org/migrations.html http://datamapper.org/getting-started.html Я это сделаю за минуты.

Я так и не услышал, чем помешает или усложнит. Можно с примерами.

Необходимость переписывать логику бд на другой язык не усложнит?)

special-k ★★★★
()
Ответ на: комментарий от baverman

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

Зачем? Если надо, у меня тонкий клиент проверит допустимость поля, и в лог что-нибудь напишет скорее всего. Только вот допустимые значения не будут захардкожены, а будут получены из базы — ей видней /что/ надо. А база не только при вводе, но и в будущем будет обеспечивать целостность и консистентность данных. Всегда. Поскольку она знает, /что/ в ней должно лежать.

тупо альтер не пройдет

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

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

Вижу, ты наконец начал улавливать суть.

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

baka-kun ★★★★★
()
Ответ на: комментарий от special-k

http://guides.rubyonrails.org/migrations.html http://datamapper.org/getting-started.html Я это сделаю за минуты.

Ну замечательно, в Руби есть свой недо-SQL. А если к БД должны обращаться программы на разных языках?

Необходимость переписывать логику бд на другой язык не усложнит?)

Для начала, определи, что ты понимаешь под «логикой». Потом скажи, на какой язык ты ее должен переписывать - с Руби на $WHATEVER? Или с SQL99 на SQL99?

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

Ну замечательно, в Руби есть свой недо-SQL. А если к БД должны обращаться программы на разных языках?

Чел.. иди читай http://ru.wikipedia.org/wiki/ORM

Для начала, определи, что ты понимаешь под «логикой».

Какую-либо дополнительную логику в работе БД, обеспечивающую консистентность данных. Мне вот тоже интересно, чего для этого достаточно помимо первичных и внешних ключей (чеки, процедуры, триггеры)?

special-k ★★★★
()
Ответ на: комментарий от tailgunner

Например юзер1 не может править коментарий юзера2, это консистентность? Как это реализовать в БД?

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

Чел.. иди читай http://ru.wikipedia.org/wiki/ORM

Поверь мне - что такое ORM, я узнал раньше тебя.

Для начала, определи, что ты понимаешь под «логикой».

Какую-либо дополнительную логику в работе БД, обеспечивающую консистентность данных.

Я не говорил об _обеспечении_ целостности данных - только о проверке.

Например юзер1 не может править коментарий юзера2, это консистентность?

Нет.

Как это реализовать в БД?

Если ты услышал «сервера приложений не нужны», то это сказал не я.

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

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

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

Пример: какое-нибудь приложение для физиков, в табличке поле - температура по шкале Цельсия. В интерфейсе (или в API, или где там еще) же будет ограничение на минимальное значение, правда? А теперь представим (дурацкую) ситуацию, когда физики имеют доступ еще и к самой базе посредством SQL... Или массовая загрузка данных выполняется сторонней утилитой, например, sqlldr (Oracle), из любого источника. Будем надеятся, что там не проскочит температура в минус сто миллиардов?

То же самое в финансах, статистике и т.д. Всегда есть риск нарушить естественные ограничения.

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

Я уж не говорю о том, что в некоторых бд (тот же Oracle) оптимизатор может принимать во внимание ограничения (ваше 2 < x <= 5) и это прямо скажется на плане выполнения. Иногда стоит дать БД больше знаний о ваших данных.

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

А вот до UPDATE FROM не допёрла. Приходится с PL/SQL блоками извращаться.

У вас, идиотов, не умеющих читать доки всегда будут такие проблемы. А всего-то надо прочитать про стандартный для SQL MERGE.

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

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

CybOrc
()

Посоветуйте годную тулзу к postgresql, аналог mysql workbench или datamodeller от oracle.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.