Данные о домене .org будет хостится на PostgreSQL

>Можно ли рассматривать такое событие как признание СУБД PostgreSQL как
>полноценной СУБД, удовлетворяющей современным требованиям,
>предъявляемым к СУБД со стороны серьезных игроков IT-рынка?

Нет, конечно.
PostgreSQL использовали и будут использовать те, кому он подходит, а все рекламные слоганы про "современнве требования" и "серьезных игроков IT-рынка" остануться там, где они нужны и оплачиваемы - на упаковках с закрытым софтом (на мешках с котами).

А как вообще держать весе записи ДНС в SQL? Дмитрий

Эх, если бы в PostgreSQL было бы : инкрементальый backup, пошаговое восстановление из журналов транзакций систему репликаций, взаимодействие с LDAP. Жить было бы счасттливее, жить было бы веселее.

Вадим Т.

2Вадим Т: Ну так добавь чего тебе не хватает :)

> Можно ли рассматривать такое событие как признание СУБД PostgreSQL как полноценной СУБД

Наконец-то *.org получит достойную СУБД :)

Я тут не совсем в курсе, но не даёт ли эти возможности SAP DB??

Удачи, Алех

Сами DNS-запросы обслуживаются не из базы. Это вообще делает другая фирма -- Afilias не предоставляет сам DNS ни для org, ни для info. В Postgres хранятся сведения о регистрации, оплате и прочее. Плюс, запросы whois с сервера whois.afilias.info тоже обслуживаются из базы.

Дмитрий 2003-01-23 14:20:06.061
В bind включена нативная поддержка нескольких backend-ов баз кроме тесктовыйх файлов. LDAP там есть и PostgreSQL, но конечно всё криво и убого.
Я использую более документированную и вообще неплохую вариацию поддержки PgSQL взятую из bind и переписанную.

http://sourceforge.net/projects/epgsqldb

Не знаю на счет серьезного ИТ рынка. Но думаю что мелких и средних проектов из Open Source лучше и не придумаешь. Да и вообще кажется в этой категории это сама полноценная база.

А почему при переходе с 7.2.xxx на 7.3.1 они поменяли форматы представления типа времени и операции с ним. Вроде и изменений на копейки, а такие проблемы. Перед этим при переходе на 7.2 была та же самая фигня. Если они типа будут менять с каждым изменением версии - нафига мне такое надо.

Вообщем следующую систему мы скорее всего не будем делать на Postgres'е.

Можно поподробнее об этом?

Дмитрий <dnu@megaart.ru>

Ну сообщение не делает им чести. Уж если Oracle дорог, что вполне реально, то менять его надо ну уж никак не PostgreSQL. Взяли бы что ли SAP DB, тоже свободная. Да и прикол в том что она умеет подерживать синтаксис SQL Oracle7 , а где-то проскакивала информация и Oracle8i. Уж с портированием все было бы намного проще.

СтранниК

про это уже тут писали

2СтранниК: PostgreSQL тоже поддерживает синтаксис Oracle, и PL/SQL тоже, только оформление немного другое.

2saper PostgreSQL тоже поддерживает синтаксис Oracle, и PL/SQL тоже, только оформление немного другое. = Ну конечно, но не это главное. Онлайн-бэкап он умеет, да и по журналу накатить изменения тоже, чего у PostgreSQL пока туговато , если не сказать еще хужей.

СтранниК

СтранниК
А не приходило в голову благородному дону, что при написании запросов нормальные программисты стараются придерживаться ANSI-синтаксиса?

А "ВЫ" - это кто?
Чтоб ненароком не воспользоваться Вашими услугами. "Если они, ТИПА, будут
менять.."
1. Зачем Вы меняли сервер? Просто так?
2. А как же SET DATESTYLE?

2AffreuxChien

Конечно приходило. Во-первых: А вы не слышали какие СУБД 100% подерживают cтандарт SQL в полной мере? Во-вторых когда портируют приложение с одной БД на другую, не очень хочется слишком переписывать приложения. Так что если есть возможность избежать переписывания, обычно ею пользуются.

СтранниК

Можно поподробней про понятия онлайн-бэкап и журнал транзакций в PostgreSQL, то есть что бы вы хотели от них(не надо кидаться ссылками на Oracle).
1. Бэкап давно уже можно делать на лету для всей базы или ее частей.
2. Журнал там есть, только вот чего он там фиксирует ... но разработчики пишут, что для восстановления после сбоя и транзакции откатятся. Я давно 2 года назад занимался проектом под PostgreSQL, очень понравился: простой и умеет много.

Очень часто читаю такое вот про backup и журнал, но не понимаю, чего кому то не хватает из того, что уже имеется.

2saper

Постараюсь на примере. Работала БД. Слягла. Необходимо восстановить данные до последней завершенной транзакции. Второй вариант: Удалили таблицу вчера( либо данные из нее ). Сегодня надо восстановить на момент перед удалением. И так делее и тому подобное. Все это выполняется с использованием системного журнала. СтранниК

> А почему при переходе с 7.2.xxx на 7.3.1 они поменяли форматы > представления типа времени и операции с ним. Вроде и изменений на > копейки, а такие проблемы. Перед этим при переходе на 7.2 была та же > самая фигня. Если они типа будут менять с каждым изменением версии - > нафига мне такое надо.

Я думал, это знают все пользователи Postgres... Когда меняется второе число в версии, это означает изменение формата представления данных на диске, что требует dump->initdb->restore. Так было всегда.

Онлайн-бекап он умеет уже давно. А другая вещь называется иначе -- Point-In-Time Recovery. Это будет в 7.4.

> Работала БД. Слягла.

Не используйте такую БэДэ!

> Удалили таблицу вчера( либо данные из нее ). Сегодня надо восстановить на момент перед удалением.

А для этого делается ежедневный бэкап.

Я пожалуй соглашусь с одним прозвучавшим здесь мнением - PostgreSQL идеально подходит тем, кому он нужен и кто хочет не кота в мешке. Возможности PostgreSQL помоему лучшие в классе Open Source СУБД. А отстегивать по $900 за юзера в Oracle - это к терапевту. Я уважаю Oracle, но такая цена - это черезчур. Опять-таки как баги выгребать, если нет сырцов? А по поводу того, чего не хватает я могу сказать, что развитие PostgreSQL идет весьма впечатляющими темпами - вот уже и схемы появились. Подождите чуть-чуть и будет все остальное. Онлайновый бакап и репликация, для тех кто не знает, есть уже сейчас. А по поводу таблицу восстановить - мне легче вырезать кусок с этой таблицей из текстового файла с бакапом и потом скормить его psql, чем бегать по журналу транзакций и искать там чего-то.

2anonymous Re: Re: Данные о домене .org будет хостится на PostgreSQL

> Работала БД. Слягла.

Не используйте такую БэДэ!

> Удалили таблицу вчера( либо данные из нее ). Сегодня надо восстановить на момент перед удалением.

А для этого делается ежедневный бэкап. Ну что тут сказать? Учите матчасть.

СтранниК

2 Я пожалуй соглашусь с одним прозвучавшим здесь мнением - PostgreSQL идеально подходит тем, кому он нужен и кто хочет не кота в мешке. Возможности PostgreSQL помоему лучшие в классе Open Source СУБД. А отстегивать по $900 за юзера в Oracle - это к терапевту. Я уважаю Oracle, но такая цена - это черезчур. Опять-таки как баги выгребать, если нет сырцов? А по поводу того, чего не хватает я могу сказать, что развитие PostgreSQL идет весьма впечатляющими темпами - вот уже и схемы появились. Подождите чуть-чуть и будет все остальное. Онлайновый бакап и репликация, для тех кто не знает, есть уже сейчас. А по поводу таблицу восстановить - мне легче вырезать кусок с этой таблицей из текстового файла с бакапом и потом скормить его psql, чем бегать по журналу транзакций и искать там чего-то. ===== Все познается в сравнении. А насчет подождать чуть-чуть я уже жду 6 лет, а воз и ныне там. Все остальное даже коментировать смешно.По журналу транзакций обычно лазить не приходится. Уважаемый anonymous хоть раз работал с БД больше гига? Если у вас нет денег на Oracle , то вполне можно использовать SAPDB. Это хоть промышленная БД. К сожалению ( и это не зависит от популярности продукта и кол-ва возможностей ) PostgreSQL - это академическая БД. И она просто не годится для более или менее серьезных приложений.

СтранниК

Мне кажется, что приятие и использование СУБД PostgreSQL в задачах, подобных представленной новости, должно послужить новым толчком в ее (СУБД) развитии. Сам факт того, что эту СУБД выбрали для решения такой задачи, мне кажется, уже может послужить хорошую службу в распространении и использовании ее где-то в корпоративной среде. И академичность здесь как раз не мешает. Может быть тормозит, но господам академикам виднее. ;)

2CruZ СУБД как мне кажется все же выбирают исходя из прикладных требований, ее стоимости , затрат на обслуживание и т.д. И совершенно все равно как эта СУБД называется. И не надо тулить горбатого до стенки. Я не спорю, что возможно в данном случае и не важна потеряются данные или нет. Если СУБД не обеспечивает требуемый для конкретной задачи надежности и сохранности данных, то грош ей цена. Это должно быть во главе угла, а не то что она свободная и у нее куча фич.

СтранниК

Если лично вам она не подходит - не используйте, это ваше право. Я хотел сказать не это. Я же не утверждаю, что эта СУБД подойдет для любой задачи. Я хочу лишь сказать, что возможно такие серьезные пользователи систему подстегнут ее развитие, хотя это далеко не факт. Вот это лично меня радует.