oleg lebedev wrote:
Если у вас был опыт с Ораклом, то будете впечатлены ещё больше. Postgres даёт полное понимание что такое транзакция. Если в вашей функции есть truncate или даже drop таблицы и вы это уже апроизвели, то вы всё равно сможете откатить транзакцию и всё восстановится как и прежде.
если произвели с kоммитом или авто коммитом, то все, что сделано, то сделано, восстановится только из бакапа или я чего-то недопоняла ?
Вы что-то недопоняли.
Backup тут совсем не причём. Мы говорили про транзакции, а это совсем другое.
Commit - это завершение транзакциии. Есть ещё другой способ завершить транзакцию. Это - rollback. В этом случае всё возвращается в исходную позицию, как до начала транзакции. Oracle и Postgres по разному это понимают. Postgres - это multiversion база и её понимание, что такое транзакция намного более глубокое, чем у Oracle. Посмотрите псевдокод:
transaction start
-- table T exists in both Oracle and PostgreSql
drop table T;
-- table T doesn't exists in either Oracle or PostgreSql
rollback;
-- transaction finished
-- table T exists in PostgreSql
-- table T doesn't exists in Oracle
Oracle говорит, мол что DDL (drop, truncate и пр.) - это не DML и не подлежит откату. Возможно это соответствует SQL стандарту, но Postgres - идёт дальше в этом деле.
Oracle подрaзuмевает более серьезное отнощение к работе! Что значит дропнул табличку случайно?!
Возможности постгреса связаны с тем что народ использует очень маленькие обьемы данных.
Для восстановления случайно удалленных табличек использюутся нетрансакционные механизмы:Flashback and recyclebin;
Вы бы не говорили бы такие глупости. Смешно даже читать.
Вы ведь тоже имеете какое-то отношение к базам данных, если решили здесь высказать своё мнение.
Вы не понимаете предмета обсуждения. Это вообще не имеет отношения к случайно удалённым таблицам. Это относится к ситуации когда drop table - это часть нормального процесса, но если возникла необходимость мы всё можем вернуть назад. Это может быть часть бизнесс логики.
Про серьёзность отношения и маленькие таблички - то мне не хочется комментировать из-за обсурдности ваших суждений.
oleg lebedev wrote:Вы бы не говорили бы такие глупости. Смешно даже читать.
Вы ведь тоже имеете какое-то отношение к базам данных, если решили здесь высказать своё мнение.
Вы не понимаете предмета обсуждения. Это вообще не имеет отношения к случайно удалённым таблицам. Это относится к ситуации когда drop table - это часть нормального процесса, но если возникла необходимость мы всё можем вернуть назад. Это может быть часть бизнесс логики.
Про серьёзность отношения и маленькие таблички - то мне не хочется комментировать из-за обсурдности ваших суждений.
oleg lebedev wrote:Орацле говорит, мол что ДДЛ (дроп, трунцате и пр.) - это не ДМЛ и не подлежит откату. Возможно это соответствует СЪЛ стандарту, но Постгрес - идёт дальше в этом деле.
Пральна все в оракле, там аутокоммит есть в ДДЛ. И раньше было очень строго, сейчас все-таки есть защита от дурака и флешбеком можно вернуть табличку недорого. Так шта недалекo постгрес ушел, но оракл стоит дороже, думаю из-за строгости его нравов
oleg lebedev wrote:Орацле говорит, мол что ДДЛ (дроп, трунцате и пр.) - это не ДМЛ и не подлежит откату. Возможно это соответствует СЪЛ стандарту, но Постгрес - идёт дальше в этом деле.
Пральна все в оракле, там аутокоммит есть в ДДЛ. И раньше было очень строго, сейчас все-таки есть защита от дурака и флешбеком можно вернуть табличку недорого. Так шта недалекo постгрес ушел, но оракл стоит дороже, думаю из-за строгости его нравов
Easbayguy wrote:
Oracle подрaзuмевает более серьезное отнощение к работе! Что значит дропнул табличку случайно?!
Возможности постгреса связаны с тем что народ использует очень маленькие обьемы данных.
и что же ето за возможности?
Easbayguy wrote:
Для восстановления случайно удалленных табличек использюутся нетрансакционные механизмы:Flashback and recyclebin;
ето утверждение опровергает 1-е: "Oracle подрaзuмевает более серьезное отнощение к работе". И по моим воспоминаниям , v oracle требуются доп. усилия что бы избавиться от мусора в базе, по умолчанию он идет в "накопитель", зато потом если "случайно" дропнул таблицу, она все равно еше в базе и ее можно извлечь из мусора. К сожаланию, разработчики oracle очень мало думают об ограниченности ресурсов.
Я боюсь, что наступит день, когда технологии превзойдут простое человеческое обшение. И мир получит поколение идиотов (c)
Ljolja wrote:т.е. Вы хотите сказать, что в орацле нет много-командных транзакций, любая команда идет как транзакция с автокомитом?
Oracle поддерживает транзакции только для DML (ins,upd,del) в то время как Postgres идёт гораздо дальше этого и поддерживает DDL в транзакции. Это принципиально более высокий уровень, который не по плечу Oracle.
Ljolja wrote:т.е. Вы хотите сказать, что в орацле нет много-командных транзакций, любая команда идет как транзакция с автокомитом?
Oracle поддерживает транзакции только для DML (ins,upd,del) в то время как Postgres идёт гораздо дальше этого и поддерживает DDL в транзакции. Это принципиально более высокий уровень, который не по плечу Oracle.
However practically any DDL will get an ACCESS EXCLUSIVE lock on the target object, making it completely inaccessible until the DDL transaction finishes. CREATE INDEX ... CONCURRENTLY is exceptional, it uses three transactions to add an index to a table while allowing concurrent updates, so it cannot itself be performed in a transaction.
Tip: Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.
Ljolja wrote:т.е. Вы хотите сказать, что в орацле нет много-командных транзакций, любая команда идет как транзакция с автокомитом?
Oracle поддерживает транзакции только для DML (ins,upd,del) в то время как Postgres идёт гораздо дальше этого и поддерживает DDL в транзакции. Это принципиально более высокий уровень, который не по плечу Oracle.
However practically any DDL will get an ACCESS EXCLUSIVE lock on the target object, making it completely inaccessible until the DDL transaction finishes. CREATE INDEX ... CONCURRENTLY is exceptional, it uses three transactions to add an index to a table while allowing concurrent updates, so it cannot itself be performed in a transaction.
Tip: Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.
Ljolja wrote:т.е. Вы хотите сказать, что в орацле нет много-командных транзакций, любая команда идет как транзакция с автокомитом?
Oracle поддерживает транзакции только для DML (ins,upd,del) в то время как Postgres идёт гораздо дальше этого и поддерживает DDL в транзакции. Это принципиально более высокий уровень, который не по плечу Oracle.
However practically any DDL will get an ACCESS EXCLUSIVE lock on the target object, making it completely inaccessible until the DDL transaction finishes. CREATE INDEX ... CONCURRENTLY is exceptional, it uses three transactions to add an index to a table while allowing concurrent updates, so it cannot itself be performed in a transaction.
Tip: Only an ACCESS EXCLUSIVE lock blocks a SELECT (without FOR UPDATE/SHARE) statement.
Зачем вы это написали?
Я не могу назвать поддержкой ДДЛ в транзакции, когда для остальных сессий/пользователей табличка исчезнет.
То есть в реальности постгресс при издании команды DROP переименовывает табличку и соответсвенно при commit, удаляет ее навсегда, а при rollback переименовывает ее обратно. То есть то что нормальные разработчики и так делают с исползованием alter table rename... при серьезных изменениях.
oleg lebedev wrote:Орацле говорит, мол что ДДЛ (дроп, трунцате и пр.) - это не ДМЛ и не подлежит откату. Возможно это соответствует СЪЛ стандарту, но Постгрес - идёт дальше в этом деле.
Пральна все в оракле, там аутокоммит есть в ДДЛ. И раньше было очень строго, сейчас все-таки есть защита от дурака и флешбеком можно вернуть табличку недорого. Так шта недалеко постгрес ушел, но оракл стоит дороже, думаю из-за строгости его нравов
Это не имеет никакого отношения к флашбацк.
Мне каецца очень логично для ДДЛ иметь аутокоммит, типа транзакция сама в себе. Флешбецк имеет отношение, чтобы им воспользоваться им, ввели то же самое, не удаление нафиг таблички, а ее переименование, чтобы если кто-то долго чешется, то мог вернуть все взад.
Ljolja wrote:т.е. Вы хотите сказать, что в орацле нет много-командных транзакций, любая команда идет как транзакция с автокомитом?
Орацле поддерживает транзакции только для ДМЛ (инс,упд,дел) в то время как Постгрес идёт гораздо дальше этого и поддерживает ДДЛ в транзакции. Это принципиально более высокий уровень, который не по плечу Орацле.
Хошевер працтицаллы аны ДДЛ шилл гет ан АЦЦЕСС ЕХЦЛУСИВЕ лоцк он тхе таргет обйецт, макинг ит цомплетелы инаццессибле унтил тхе ДДЛ трансацтион финишес. ЦРЕАТЕ ИНДЕХ ... ЦОНЦУРРЕНТЛЫ ис ехцептионал, ит усес тхрее трансацтионс то адд ан индех то а табле шхиле аллошинг цонцуррент упдатес, со ит цаннот итселф бе перформед ин а трансацтион.
Тип: Онлы ан АЦЦЕСС ЕХЦЛУСИВЕ лоцк блоцкс а СЕЛЕЦТ (шитхоут ФОР УПДАТЕ/ШАРЕ) статемент.
Зачем вы это написали?
Я не могу назвать поддержкой ДДЛ в транзакции, когда для остальных сессий/пользователей табличка исчезнет.
То есть в реальности постгресс при издании команды ДРОП переименовывает табличку и соответсвенно при цоммит, удаляет ее навсегда, а при роллбацк переименовывает ее обратно. То есть то что нормальные разработчики и так делают с исползованием алтер табле ренаме... при серьезных изменениях.
Так типо вопрос, а в постгресе есть временные таблички, которые как в оракле исчезают когда сессия закончилась? Если есть, то все навороты в аппликации с созданием и удалением таблиц == плохое решение
Likenew wrote:
Так типо вопрос, а в постгресе есть временные таблички, которые как в оракле исчезают когда сессия закончилась?
Есть (CREATE TEMPORARY ... [ON COMMIT]). В двух режимах - те, которые исчезают после того, как завершилась сессия юзера и те (ON COMMIT) которые исчезают после завершения транзакции. Но там есть отличия от стандарта, которые нужно иметь в виду - в стандарте можно один раз обьявить временную таблицу и она будет создаваться/удаляться, а в Постгрессе каждая сессия должна сама явно вызывать CREATE TEMPORARY (что фактически позволяет в различных сессиях создавать временные таблицы с одинаковым именем, но с разной схемой).
и что же ето за возможности?
