powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Чем плох блокировочник по сравнению с версионником?
25 сообщений из 370, страница 2 из 15
Чем плох блокировочник по сравнению с версионником?
    #38953021
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousНу так SAVEPOINT перед каждым запросом и всего делов.
1. Не очень понимаю, как savepoint спасёт от отката транзакции.

2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД "savepoint перед каждым запросом" обеспечивают автоматом.
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953035
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД
"savepoint перед каждым запросом" обеспечивают автоматом.
Ну так PG, видимо, не претендует...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953038
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousDimitry SibiryakovКлиент должен принять решение. Решит откатывать - пусть откатывает. Решит закоммитить как
есть - пусть коммитит как есть. Решит использовать любую другую логику обработки конфликта
- ему и карты в руки. Потому что это его бизнес-логика, его мабиноги.

Ну так SAVEPOINT перед каждым запросом и всего делов.

Я вот только не могу понять, как бизнес-логика связана с конфликтами и зачем ей вообще что-то о них знать?

Зачем я в своих транзакциях должен использовать не SERIALIZABLE и предусматривать специальную обработку всех возможных ситуаций (в которой, IMHO, запросто могут ошибиться 99% программистов) вместо общего framework-а (при ошибке откатил-повторил)?Мне одному кажется, что вы какой-то бред несете?
1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные. Отсюда и deadlocks встречаются редко. Наличие большого количеств deadlock говорит либо о кривости самого приложения, либо о кривости СУБД (слишком крупные блокировки)
2) Exception на то и exception, что мы заранее не знаем, какой он может произойти. Может быть deadlock, а может и место на сервере закончиться. На каждый случай условных веток не напасешься. Но всегда есть возможность написать обработчик others, который будет всегда откатывать транзакцию, показывать юзеру текст exception и предлагать повторить всю транзакцию с нуля. Какие к черту SAVEPOINT?
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953040
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexander RyndinМне одному кажется, что вы какой-то бред несете?
Да не то чтобы бред. Слова уважаемого коллеги напоминают мне поведение юного головастого студента с большим самомнением, который нахватался вершков теории и при нуле практики начал придумывать улучшения и прочие единственно правильные подходы.
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953072
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer1. Не очень понимаю, как savepoint спасёт от отката транзакции.

Может откатиться до него.

softwarer2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД "savepoint перед каждым запросом" обеспечивают автоматом.
О каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде, а если не нужна --- не буду использовать. А в Ваших "нормальных СУБД" выбора нет, получается? И это Вы выдаёте за преимущество? ;)
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953074
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakovsoftwarer2. Возможно, Вам нравится выступать обезьянкой, но нормальные СУБД
"savepoint перед каждым запросом" обеспечивают автоматом.
Ну так PG, видимо, не претендует...

С чего это наличие или отсутствие произвольных ограничений вдруг стало определять "нормальность" СУБД?
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953077
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousС чего это наличие или отсутствие произвольных ограничений вдруг
стало определять "нормальность" СУБД?
С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953083
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alexander RyndinМне одному кажется, что вы какой-то бред несете?
Откуда я знаю, сколько вас здесь, "считающих"? ;)

Alexander Ryndin1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные. Отсюда и deadlocks встречаются редко.
А статистика, подтверждающая "в редких приложениях", у Вас есть? Или это информация агенства ОБС? ;) И как связаны "меняют разные данные" и DEADLOCK-и? Пускай 100500 клиентов конкурируют за одни и те же строки, но если они обрабатывают их в одном порядке, DEADLOCK-ов (без слишком крупных блокировок и т.п.) не будет вообще.

Alexander Ryndin Наличие большого количеств deadlock говорит либо о кривости самого приложения, либо о кривости СУБД (слишком крупные блокировки)

Обычно да.

Alexander Ryndin2) Exception на то и exception, что мы заранее не знаем, какой он может произойти. Может быть deadlock, а может и место на сервере закончиться.

Безусловно, какой будет exception, заранее неизвестно. Но вот deadlock-и и update conflict-ы --- это нормальные ситуации в работе СУБД, и любому Database Developer должно быть известно, как их полагается обрабатывать.

Alexander RyndinНа каждый случай условных веток не напасешься.

Можно и напастись, т.к. обычно ошибки как-то разделяются на группы по severity и т.п.

Alexander RyndinНо всегда есть возможность написать обработчик others, который будет всегда откатывать транзакцию, показывать юзеру текст exception и предлагать повторить всю транзакцию с нуля.

Да Вы что? А если пользователя просто нет ? Кому Вы будете это сообщение показывать?

Alexander Ryndin Какие к черту SAVEPOINT?
Те самые, которые есть в стандарте и во всех "нормальных СУБД"? Вот они все дураки-то, правда? ;)
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953086
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymoussoftwarer1. Не очень понимаю, как savepoint спасёт от отката транзакции.

Может откатиться до него
На предыдущем допросе (тм) Вы показали, что версионник должен отказывать транзакцию. Как откатиться до savepoint-а после отката транзакции и зачем?

PgSQLAnonymousО каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде,
Вот именно о таких обезьянках.

PgSQLAnonymousА в Ваших "нормальных СУБД" выбора нет, получается? И это Вы выдаёте за преимущество? ;)
За преимущество я выдаю удобную и правильную работу. А мучающиеся с грязным чтением, мумпсом и прочим каменным веком имеют полное право гордиться тем, что у них зато есть выбор.
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953090
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovPgSQLAnonymousС чего это наличие или отсутствие произвольных ограничений вдруг
стало определять "нормальность" СУБД?
С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:
Код: sql
1.
2.
3.
4.
BEGIN;
INSERT INTO history_table SELECT * FROM current_table;
TRUNCATE TABLE current_table;
COMMIT;


И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается , и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953093
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarerAlexander RyndinМне одному кажется, что вы какой-то бред несете?
Да не то чтобы бред. Слова уважаемого коллеги напоминают мне поведение юного головастого студента с большим самомнением, который нахватался вершков теории и при нуле практики начал придумывать улучшения и прочие единственно правильные подходы.
А мне Ваши, может, тоже чего-то напоминают. А аргументы-то есть у Вас?
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953096
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarerPgSQLAnonymousпропущено...
Может откатиться до него
На предыдущем допросе (тм) Вы показали, что версионник должен отказывать транзакцию. Как откатиться до savepoint-а после отката транзакции и зачем?
Естественно, никак. Он может откатиться до savepoint-а вместо отката транзакции, если это нужно.

softwarerPgSQLAnonymousО каких "обезьянках" речь? Если мне нужна будет "savepoint перед каждым запросом", я это легко реализую в клиентском (да и серверном) коде,
Вот именно о таких обезьянках.
Нда. То есть возможность наличие выбора и возможность тривиально реализовать implict savepoint --- это недостаток, а отсутвие выбора --- это преимущество? Интересная у Вас логика.

softwarerЗа преимущество я выдаю удобную и правильную работу. А мучающиеся с грязным чтением, мумпсом и прочим каменным веком имеют полное право гордиться тем, что у них зато есть выбор.
Как здесь появились "грязное чтение, мумпсом и прочий каменным век"?
Ни с чем таким в PostgreSQL и MS SQL, например, где вышеописанный выбор есть, можно не мучаться (а с грязным чтением в PostgreSQL и не получится)...
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953103
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousмне это поведение почему-то совсем не кажется "нормальным"
Выше я уже писал про неестественный интеллект и инициативу. Ты явно и недвусмысленно
приказал серверу закоммитить транзакцию не смотря ни на что. Он её закоммитил. Почему
точное выполнение сервером твоих приказов ты считаешь ненормальным?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953113
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovPgSQLAnonymousмне это поведение почему-то совсем не кажется "нормальным"
Выше я уже писал про неестественный интеллект и инициативу. Ты явно и недвусмысленно
приказал серверу закоммитить транзакцию не смотря ни на что. Он её закоммитил. Почему
точное выполнение сервером твоих приказов ты считаешь ненормальным?

Я говорю, что мне это поведение кажется ненормальным, потому что я привык к другому. ;) Если его учитывать, то ничего плохого тут нет, я приказал --- он закоммитил, формально косяк здесь только мой. Но без implicit savepoints я могу выполнить это всё одним запросом/пакетом и знать, что данные не потеряются, а здесь нет, и это мне кажется ненормальным. ;(
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953119
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousDimitry Sibiryakovпропущено...

С тех пор как атомарность транзакции в целом и DML в частности стала стандартом.

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:
Код: sql
1.
2.
3.
4.
BEGIN;
INSERT INTO history_table SELECT * FROM current_table;
TRUNCATE TABLE current_table;
COMMIT;


И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается , и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)

Я дико извиняюсь, что встреваю, но, в нормальной СУБД:

Код: sql
1.
DELETE current_table OUTPUT deleted.* INTO history_table
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953129
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pkarklinPgSQLAnonymousпропущено...

Извините, этого я не понял вообще. Стандарт ANSI SQL не требует implicit savepoints. О каком стандарте идёт речь и причём тут атомарность-то?
Как вообще наличие или отсутвие implicit savepoints влияет на атомарность?

Кстати, Вам не кажется, что Вы всё наоборот вывернули? Вот, например, если у меня есть "нормальная СУБД" и я выполняю:
Код: sql
1.
2.
3.
4.
BEGIN;
INSERT INTO history_table SELECT * FROM current_table;
TRUNCATE TABLE current_table;
COMMIT;


И у меня происходит ошибка в INSERT, то, как я понимаю, он откатывается и транзакция продолжается , и мне это поведение почему-то совсем не кажется "нормальным". Верни мои данные, проклятый сервер! ;)

Я дико извиняюсь, что встреваю, но, в нормальной СУБД:

Код: sql
1.
DELETE current_table OUTPUT deleted.* INTO history_table



А в другой нормальной СУБД:
Код: sql
1.
2.
3.
4.
WITH deleted AS (
DELETE FROM current_table RETURNING *
)
INSERT INTO history_table SELECT * FROM deleted;


И что? ;)
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953131
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousИ что? ;)
Это был намек, что скрипт был приведен "под ситуацию".
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953151
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pkarklin,

а воще то все эти output и returning убожество мысли и отсутствие фантазии с целю достичь атомарности в некоторых простых случаях

и говно тот субд который СВОЮ работу валит на плечи клиента, а дедлоки и конфликты именно работа субд, без оных нах субд и не нужна, кроме как читать она ни для чего не нужна
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953153
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexander Ryndin1) В редких приложениях встречается жесткая конкуренция за одни и те же строки. Обычно в многопользовательском режиме пользователи меняют разные данные.
это так кажется
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953606
const64
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousА что хорошего в версионнике? Бесконечные откаты при высокой конкуренцииЗвучит двусмысленно...
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953957
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Думаю, "неправильные" - очень неудачное слово.
Ну не очень неудачное. Как бы правило - читать в БД то, что в ней хранится в согласованном состоянии: т.е. результат завершенных транзакций. Несогласованные данные ("грязные") ну не правильные - таких не должно быть в БД. Согласованные типа как бы правильные. На момент запроса в БД именно такие данные. Хотя они в процессе изменения - как бы не совсем актуальные: раз меняют значит в там должны бы быть другие. Ну так это вопрос оперативности. Если это не правильно, то может быть, просто нужна типа система реального времени.
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953963
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfosoftwarerДумаю, "неправильные" - очень неудачное слово.
Ну не очень неудачное. Как бы правило - читать в БД то, что в ней хранится в согласованном состоянии
Именно. Насколько я понял Сергея, "неправильными" данными он назвал "те значения, которые вот-вот будут изменены, а мы их читаем".
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953975
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoКак бы правило - читать в БД то, что в ней хранится в согласованном
состоянии: т.е. результат завершенных транзакций. Несогласованные данные ("грязные") ну не
правильные - таких не должно быть в БД. Согласованные типа как бы правильные. На момент
запроса в БД именно такие данные.
Неясно только зачем ограничиваться согласованностью данных на уровне запроса. На уровне
транзакции оно гораздо полезнее: можно выдать сколько угодно запросов и полученные ими
данные будут согласованы как унутре резалт-сета, так и между собой.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953988
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarervadiminfoпропущено...

Ну не очень неудачное. Как бы правило - читать в БД то, что в ней хранится в согласованном состоянии
Именно. Насколько я понял Сергея, "неправильными" данными он назвал "те значения, которые вот-вот будут изменены, а мы их читаем".
Ну я тоже так понял. Но это как бы это все же особые требования к оперативности. Но если данные про то, чего не могло быть не до не после изменения, то они совсем неправильные.
Впрочем, я согласен, что термин "правильные" не подходит для строго описания. Выбран чисто для упрощения описания.
...
Рейтинг: 0 / 0
Чем плох блокировочник по сравнению с версионником?
    #38953995
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PgSQLAnonymousЕстественно, никак. Он может откатиться до savepoint-а вместо отката транзакции, если это нужно.
Замечательно. То есть предыдущее утверждение явно дезавуируем.

PgSQLAnonymousНда. То есть возможность наличие выбора
Выбор - не преимущество. Уместный выбор - преимущество. Неуместный выбор - недостаток.

Установка savepoint-а бесплатна и ничему не мешает. Поэтому выбор - неуместен, и необходимость в каких-то дополнительных телодвижениях для того, чтобы он был поставлен - недостаток.

PgSQLAnonymousКак здесь появились "грязное чтение, мумпсом и прочий каменным век"?
Как пример "выборов", которые по Вашей логике, являются преимуществом.

PgSQLAnonymousНи с чем таким в PostgreSQL и MS SQL, например, где вышеописанный выбор есть, можно не мучаться (а с грязным чтением в PostgreSQL и не получится)...
Ну вот и очень плохо, что не получится Такие нехорошие, выбор отобрали
...
Рейтинг: 0 / 0
25 сообщений из 370, страница 2 из 15
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Чем плох блокировочник по сравнению с версионником?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]