LINUX.ORG.RU
← Поставки CherryOS приостановлены
Интервью с Mitch Kapor →

неплохо!

anonymous
()

Спасибо, чувак, что запостил. Хорошая статейка, образец для постов на ЛОРЕ.

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

> Когда восьмерка появится в дебильане-то...?

apt-cache policy postgresql-8.0
postgresql-8.0:
  Installed: (none)
  Candidate: 8.0.1-3
  Version Table:
     8.0.1-3 0
        250 ftp://ftp.debian.org ../project/experimental/main Packages

blahamuha ★
()

Супер, особенно Pervasive Postgres порадовал! Неплохое признание качества PostgreSQL сервера!

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

да статья грамотная, но есть глючек в табличке - не знаю что такое Partial index но Inverted index у оракла есть. Tablespace & Schema у mssql будет только в юконе.

anonymous
()

Статья хорошая. Грамотная. PostgreSQL хорошо описан. Больше всего порадовало, правда, не всё содержание, а то, что в 8.1 ожидаются IN, OUT и INOUT ;-)

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

Да, кстати Pervasive Postgre под винды 40 Метров весит!

А это значит что наработки команды Pervasive по разработке SQL доступны теперь и под Postgre, сохраняя полную совместимость! Круто товарищи!

Lautre ★★★★★
()

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

Авторам респект.

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

> ээээ, это с каких пор нет бэкапа в постгре??
> в 8ке он вообще автоматический, если хочешь

он видимо имел ввиду автоматическую репликацию - по аналогии с мускулем:
для создания распределенных кластеров.

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

читаем статью...
vvvvvvvvv
Репликация также повышает надежность PostgreSQL. Существует несколько систем репликации, например, Slony, который является свободным и самым используемым решением, поддерживает master-slaves репликацию. Ожидается, что Slony-II будет поддерживать multi-master режим.
---
это я не вкурил ? или кто-то статью не читал даже?(а тем более доки)

XuMiX
()

ойей, меня статья запугала досмерти

мануал на 1300 страниц! Столько мое недоразвитое умишко не всосет..

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

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

Пойду смотреть...

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

Ты еще про оракл не смотрел....

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

На пальцах просто.. >Кстати, а кто-нибудь на пальцах может рассказать что такое репликация? И что она позволяет делать?

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

Основа - состаавной ключ из 2х полей в любой реплицируемой таблице (автоинкремент и имя подразделения например)

Существует давно.

Кое где работает.

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

Slony-I не входит в состав postgresql. Я бы не сказал, что это самое используемое решение для репликации postgresql, скорее самое используемое open-source решение, но недостатков у него все же хватает.

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

>Slony-I не входит в состав postgresql.

Sybase держал обновляемые реплики неплохо. Отруливал коллизии обновления и т.п. Когда-то был приятный легкий в освоении серверок.

Слоненок пока сыроват. ИМХО чем с орепликами (которые не read only) возится сейчас проще связь наладить.

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

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

Не путай человека. Посмотри на http://replication.chat.ru/

Репликация (синхронизация) - процесс приведения данных электронных таблиц двух (или более - teodor) БД в идентичное состояние.

Репликацию можно классифицировать по разному. В рамках данной статьи возьму на себя смелость остановиться на следующем варианте:

I. По направлению репликации. Если данные изменяются только в одной из БД, а в другой данные только хранятся и не подвергаются изменениям, то такую репликацию будем называть однонаправленной или односторонней. Если же данные могут изменяться и вводиться на всех БД, то такой вид репликации будем называть мультинаправленной или многосторонней.

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

III. По способу передачи информации во время процесса репликации. Если соединение серверов, хранящих распределенные БД, происходит при помощи программы клиента, которая с одной стороны коннектится к своему серверу, а с другого конца имеет прямую связь с БД другого сервера и может подключиться напрямую к данным другого сервера, для прямого изменения и анализа реплицируемых данных с обеих концов, имея при этом гарантированный устойчивый канал связи (ADSL, выделенный канал, двупроводная линия Dial-Up и пр.), то такой вид синхронизации назовем прямым. Если же канал неустойчивый и не гарантирует устойчивую связь без падений во время процесса синхронизации и данные приходится передавать цельными пачками, при этом принимающая сторона во время закачки и анализа данных не имеет немедленной возможности опросить источник при возникновении на ее взгляд сомнительных моментов, а решение "Что делать?" принимать в любом случае нужно, то такой вид синхронизации будем называть недетерминированной или вероятностной.

IV. По способу анализа реплицируемой информации. Если ядро алгоритма работает по принципу сравнения записей одной таблицы с записями другой, и на основании этого принимается решение о синхронизации, то такой процесс будем называть репликацией по текущему состоянию. Если в базе предусмотрен журнал вносимых изменений в БД, и алгоритм репликации переносит измененя по дельтам изменений накопленным в журнале, то такой процесс назовем дельта репликацией.

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

2teodor

>Не путай человека....

Это для академиков. А просили на пальцах :). Я больше не по теоретическим книжкам, а по сайбейсовским докам. C "недетерменированностью" у меня туго... А после того что ты запостил, я засомневался даже(и как оно у меня все работало?)

Это все равно что про майского жука, который летает потому как не хнает законов физики :)

anonymous
()

Здоровски!
Орфографические ошибки бы подчистить и хороший материал для истории.
ЛОР однако исправляется в лучшую сторону :)
Учитывая появление хороших исторических статей предлагается на LOR создать раздел "История OpenSource" и туда помещать подобные материалы. В качестве первых кандидатов можно включить "история Linux" опубликованная на LinuxCenter http://www.linuxcenter.ru/lib/articles/lh-00.phtml и туда же поместить и эту статью о постгресе. Получится хороший исторический раздел.

Ну не вечно же флеймить на тему "Windows против Linux" и наоборот %)
тем более что www.opensource.ru = www.linux.org.ru

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

>2OpenStorm

>ЛОР однако исправляется в лучшую сторону :)

Лор так же неисправим, как и общество, потому как являетя частью последнего. Не будь идеалистом.

Ну а насчет windows и linux.. Люди делятся на 2 категории. Одни про это флеймят, а другие в этом немного разбираются.

Статья полезная. Респект.

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

>если есть что добавить в табличку сравнений, то сделай это здесь:
...

Сам только что туда глянул (давно не заглядывал) - там столько сравнений возможностей, что оглохнуть можно %)

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

> ЛОР однако исправляется в лучшую сторону :)

ЛОР, как и любой сайт делают живые люди - вопрос стоит в тех кто сюда заглядывает и насколько они знают о linux. Просто народ больше узнал о linux, как принято говорить в бизнесе - лояльность пользователей к марке растет :)

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

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

Не очень понятно, что за такие сомнительные моменты. Вот взять, например, ораклиную ручную репликацию (для точности, например, Oracle Dataguard из Oracle 9.2.0.5). Передаются изменения, накопленные в журнале (archived logs). Передаются пачками. В случае ручной репликации - руками администратора или скриптом. Какая там недетерминированность?

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

>Если кому интересно, документация по PostgreSQL 8.0.1 (частично переведена): >http://www.linuxshare.ru/postgresql/manual/index.html

по-моему лучше воспользоваться руководством, которое поставляется с исходниками, там есть и русское (достаточно объемное).

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

> Но решения ооооочень интересные (триггера и функции на всем что
> компилится и интерпретируется это круто). И ведь работает, как ни
> странно!

Обалдеть! Триггера и функции на Лиспе или Схеме есть?

Была такая БД framerd, там встроенный интерпретатор Схемы,
кто-нибудь пробовал? А то видно она давно уже не развивается.

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

> Есть на: C, PL/php, PL/I, PL/SQL, PL/PGSQL, PL/Perl, PL/Java, PL/TCL

PL/Python забыто

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

>Есть на: C, PL/php, PL/I, PL/SQL, PL/PGSQL, PL/Perl, PL/Java, PL/TCL

>Вам мало? ;))

>stellar (*) (07.04.2005 10:25:00)

Мало :-) Лиспа не хватает.

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

Бррррр... А с какой радости пакет cl-postgresql или как там еще его, точно не помню, в демьяне существует? Выхвати его и поимей счастье, наконец.

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

$ apt-cache show cl-sql-postgresql
Package: cl-sql-postgresql
Priority: extra
Section: devel
Installed-Size: 132
Maintainer: Kevin M. Rosenberg <kmr@debian.org>
Architecture: all
Source: cl-sql
Version: 3.1.2-1
Provides: cl-sql-backend
Depends: cl-sql (>= 3.1.2-1), postgresql-dev, cl-sql-uffi (>= 3.1.2-1)
Filename: pool/main/c/cl-sql/cl-sql-postgresql_3.1.2-1_all.deb
Size: 37406
MD5sum: 6677f4ba257e31cb0558d2a5f93605cf
Description: CLSQL database backend, PostgreSQL
This package enables you to use the CLSQL data access package
with PostgreSQL databases.
CLSQL is a Common Lisp interface to SQL databases.

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

> Мало :-) Лиспа не хватает.

Так ведь ерунда какая... Ну напишите!.. :)

Триггеры и процедуры к pg на CL - cool!!! :)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Поставки CherryOS приостановлены
Open Source
Интервью с Mitch Kapor →