Как стать автором
Обновить

Комментарии 25

а Postgres-XC и Postgres-XL это сторонние разработки или фичи из коробки?
Странно, был уверен что пострес умеет кластер из коробки. Пойду чинту
Это сторонние разработки. Postgres-XC — предшественник Postgres-XL. Кстати, разработчик Postgres-XL Mason Sharp будет делать доклад на pgconf.ru. Подробности про XL и XC тут www.translattice.com/postgres_compare.shtml
Постргрес прекрасен. Видел тыщи мест, куда горе-интеграторы (бабло не пахнет, ага ага) тянут ора-кал за много денег, когда там бесплатный постгрес все прекрасно сделал бы.
Самая известная, конечно, Oracle, сегодня это общепризнанная СУБД №1 в мире
Очень спорное и странное утверждение.
Ок, почитайте, по вашей ссылке есть методика этой оценки. Вкратце — Oracle это СУБД которая чаще всего упоминается в Интернете. Самая известная? Да, пожалуй, можно так сказать по этому рейтингу. Признанная? №1? Боюсь тут так просто не оценишь, слишком широка предметная область.
Но искать по правильному названию в интернете не выглядит как надежный способ найти все упоминания этой СУБД.
Возможно что именно название и не даёт взлететь выше, искать действительно тяжеловато.
Скажите, пожалуйста, Вы не в курсе, планируется ли запись (с возможностью ее посмотреть или купить для просмотра) или интернет-трансляция мероприятия?
Трансляция не планируется. Запись будет, но условия ее распространения будут объявлены после мероприятия.
Чтобы популяризовать postgres нужно создать сертификацию… Ох уж этот отечественный подход.
Ну, там говорится не про популяризацию, а о доступе на рынок решений для тех потребителей, которым оная сертификация требуется. Такое случается и за «бугром».
Арендовать аудиторию можно на три часа, а можно на 15 минут. Требуется, чтобы лекции не пересекались в пространстве-времени. Для этого unique constraints, естественно, не подходят. Тут помогут exclusive constraints, чтобы можно было гарантировать, что эти два временных интервала в одной аудитории не пересекаются.
Бизнес-логика в СУБД? Стоит ли?
Не бизнес-логика в СУБД, а корректное описание типов в СУБД.
Корректность и консистентность данных — это как беременность, либо она есть, либо её нет.

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

Вы правда хотите проверять всё-всё вручную? Конечно, есть ситуации, когда проще проверять в приложении — например, когда нужно проверить статус чего-либо во внешней системе, но 99% проверок можно унести на уровень СУБД и рассматривать это как простой и гибкий валидатор ваших данных (и, к тому же, очень быстрый)
На какие ухищрения придется пойти, чтобы поменять местами два занятия в расписании, например?
Если вы описали непересекаемость занятий в расписании как constraint, и меняете их в одной транзакции — то почти никаких, вот эту штуку только передёрнуть в начале транзакции www.postgresql.org/docs/9.3/static/sql-set-constraints.html
DEFERRED | IMMEDIATE
О, это классная штука, не знал, спасибо.
Важно, что exclusion constraints берут на себя заботу о конкурентности. Если, например, просто проверять перед вставкой отсутствие противоречий, то будет race condition. Если лочить таблицу целиком – медленно. А делать на уровне приложения реализацию аналогичную exclusion constraints –  муторно.
Да, в таком сценарии это безусловно плюс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий