это если ID монотонно возрастают. Или хранить timestamp создания и последнего обновления

Вот база данных, единственный админ (пользователь) просмотрел все данные, со второго раза когда хочет просмотреть записи, должны показываться только новые (непросмотренные)

Т.е. после SELECT * FROM a JOIN b ON ... LEFF JOIN x ... WHERE <complex-condition>; вы хотите, чтобы любой следующий запрос не возвращал те записи, которые были выбраны в первом?

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

Т.е. после SELECT * FROM a JOIN b ON ... LEFF JOIN x ... WHERE <complex-condition>; вы хотите, чтобы любой следующий запрос не возвращал те записи, которые были выбраны в первом?

именно

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

не вариант

не вариант

вариант

именно

Ничего себе! Слушайте, а вам это зачем?

почему? делаете инбокс для пользователя, на вставке вставляете ему всё в инбокс, на чтении удаляйте

Ничего себе! Слушайте, а вам это зачем?

спасибо))))

решение железнобетонное и не противоречит вашим требованиям

вариант

Не вариант.

Там 40 таблиц в одном запросе может участвовать, почему нет?

не вариант

Да можно... Удаляешь записи, делаешь повт. SELECT, потом опять удаляешь, потом в конце — ОТКАТЫВАЕШЬ ТРАНЗАКЦИЮ!

Да можно... Удаляешь записи, делаешь повт. SELECT, потом опять удаляешь, потом в конце — ОТКАТЫВАЕШЬ ТРАНЗАКЦИЮ!

С каких пор у нас многотабличное удаление появилось?

А где я тебе говорил про многотабличное удаление?

А где я тебе говорил про многотабличное удаление?

А вы пояснение автора читали?

А вы пояснение автора читали?

а где у автора про многотабличность, я перечитал и не вижу?

Вот база данных, единственный админ (пользователь) просмотрел все данные, со второго раза когда хочет просмотреть записи, должны показываться только новые (непросмотренные)

а речь про пользователя базы данных или приложения, которое обращается к базе?

именно

А вот она... если я правильно понял.

приложение

А вот она... если я правильно понял.

так про join оно от вас, от автора подтверждения именно про join я не вижу

так про join оно от вас, от автора подтверждения именно про join я не вижу

Так он на моё сообщение ответил "именно"...

И?

Автор, вы в самом деле имели в виду это?

Чего он там имел в виду — даже не важно. Надо удалять из одной таблицы — пожалуйста. Надо из нескольких — пожалуйста. Всё равно это надо в одной транзакции делать.

Чего он там имел в виду — даже не важно. Надо удалять из одной таблицы — пожалуйста. Надо из нескольких — пожалуйста. Всё равно это надо в одной транзакции делать.

А по-моему, важно. Вопрос в том, что именно и откуда удалять.

Да пусть всё что угодно удаляет, это его проблемы уже.

приложение

А админ читает записи по одной или все разом?

Да пусть всё что угодно удаляет, это его проблемы уже.

Да, но ваш ответ напоминает анекдот про "А вы станьте ёжиками.". ;)

А как удалять? Допустим есть таблица A (id, payload) {(1, a)} B(id, aid, payload) {(10, 1, z)} Посмотрел, стёрлись записи. Потом появляется в запись (11, 1, x), которая должна бы цепляться к А по LEFT JOIN, но А уже вся просмотрена и удалена!

А админ читает записи по одной или все разом?

все разом

все разом

Вообще это очень странная задача... вы уверены, что это не про одну таблицу? ;)

ой, тогда есть крамольная тема!

индекс по xid

А как удалять? Допустим есть таблица A (id, payload) {(1, a)} B(id, aid, payload) {(10, 1, z)} Посмотрел, стёрлись записи. Потом появляется в запись (11, 1, x), которая должна бы цепляться к А по LEFT JOIN, но А уже вся просмотрена и удалена!

Чтобы запись не светилась в запросе, достаточно хотя бы с одной стороны JOINа удалить, если LEFT JOIN, то нужно с ЛЕВОЙ стороны. А там уже гляди сам, что тебе нужно по логике задачи удалять.

Чтобы запись не светилась в запросе, достаточно хотя бы с одной стороны JOINа удалить, если LEFT JOIN, то нужно с ЛЕВОЙ стороны. А там уже гляди сам, что тебе нужно по логике задачи удалять.

вот именно. Если записи добавятся в другие таблицы, то они уже не покажутся при таком подходе

индексом по xid порешали репликацию в osm, но теперь так нельзя: https://github.com/openstreetmap/operations/issues/154

а если админ сонный был? невнимательно посмотрел, а повторно уже не увидит)))

Добрый день! кто нибудь может направить, есть база данных, первый раз просмотрели записи, а второй раз уже должны показываться только новые записи (непросмотренные)... как можно это сделать

Но я думаю, что всё же ты решаешь XYProblem, скорее всего просто тебе надо делать флажок "ПРОСМОТРЕНО" на уровне приложения , и ставить его (и проверять в ввыводе естественно). Транзакции такие длинные вряд ли тебе понравятся.

вам обычную пагинацию и все, показывать все последние энцать записей,... остальное уходит на вторую треюю и далее страницы

все разом

тогда как насчет вот этих вариантов:

вот именно. Если записи добавятся в другие таблицы, то они уже не покажутся при таком подходе

Это автор вопроса должен решать

хранить на клиенте ИД последнего просмотренного?)

это если ID монотонно возрастают. Или хранить timestamp создания и последнего обновления

подходят?

Но я думаю, что всё же ты решаешь XYProblem, скорее всего просто тебе надо делать флажок "ПРОСМОТРЕНО" на уровне приложения , и ставить его (и проверять в ввыводе естественно). Транзакции такие длинные вряд ли тебе понравятся.

Я тоже надеюсь, что так... но автор молчит. :(

хранить на клиенте ИД последнего просмотренного?)

Да это только для pagination подходит, "просмотреть непросмотренные" так не решишь.

безнадежно всё это. Если автор так задает вопросы по своей проблеме , то в таком же ключе он всё и понимает ему предложенное.

Да это только для pagination подходит, "просмотреть непросмотренные" так не решишь.

можете раскрыть мысль?

туплю >_<

почему только для пагинации?

лочить на уровне строк показывать незалоченные строки

Добрый день! кто нибудь может направить, есть база данных, первый раз просмотрели записи, а второй раз уже должны показываться только новые записи (непросмотренные)... как можно это сделать

У вас по сессиям этот механизм pаботает? Если да – делаете таблицу связей, и View с флагом, опpеделяющим наличие связи. Pезонно делать обновление по меpе накопления буффеpа пpосмотpов.

Если нет – максимально банальное pешение – отдельная табличка с метаданными о том, что было пpосмотpено, а что – нет.

можете раскрыть мысль?

Я думал, что под id вы имели в виду sequence, нет? Так они принципиально не атомарны, и для таких вещей, естественно, не подходят.

лочить на уровне строк показывать незалоченные строки

Вот это идея! ;)

Да, sequence. Если я сделал SELECT, сохранили себе максимальный id из записей, полученных таким селектом. И следующий селект сделаю с условием WHERE id > сохраненный id, я получу неожиданное?

Вот это идея! ;)

я просто недавно в одном проекте видел чтото такое сейчас попробую найти что там было, сам ниразу не использовал еще)

но там это было для одновременного доступа к одним и тем же данным что бы распаралелить обработку

И после того, как вы прочитали записи и сохранили себе максимальный id, происходит COMMIT транзакции, которая вставила запись с меньшим id, чем вы запомнили. Ups.

спасибо.

И после того, как вы прочитали записи и сохранили себе максимальный id, происходит COMMIT транзакции, которая вставила запись с меньшим id, чем вы запомнили. Ups.

зависит от требований к гарантиям

зависит от требований к гарантиям

То есть? Обсуждалась задача "прочитать всё ранее не прочитанное", нет?

да, но возможно при анализе окажется, что требование более мягкое, "не показывать записи более одного раза"

Что ты так уперлись в задачу этого упоротого чувака? Она явно на бд не ложится в его понимании. Надо просто фильтровать по дате и все

да, но возможно при анализе окажется, что требование более мягкое, "не показывать записи более одного раза"

О, да это вообще просто: SELECT * FROM t LIMIT 0; ;) Но, если серьёзно, да, тут надо ждать автора...

Что ты так уперлись в задачу этого упоротого чувака? Она явно на бд не ложится в его понимании. Надо просто фильтровать по дате и все

джентельмены хотели поговрить, нужен был только повод :)

Что ты так уперлись в задачу этого упоротого чувака? Она явно на бд не ложится в его понимании. Надо просто фильтровать по дате и все

а давайте постараемся без переходов на личности? :)

Ок)

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

делайте просто вьюху на функцию возвращающую таблицу в функции уже реализуете вашу логику как вам угодно

и лучше сразу себя отучить от мысли что с базой будет работать только 1 пользователь, получается он же суперюзер лучше сразу отделить админа (суперпользователя) от пользователя системы

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

Если люди пытаются системными средствами решать задачи уровня приложения (прикладные) это уже сразу же почти гарантированно неверно.

Есть большая таблица, есть маленькая таблица того же формата и диапазон первичных ключей. Не подскажете как лучше одной операцией заменить все записи в большой таблице принадлежащие диапазону записями из маленькой таблицы, причём просто удалить и добавить нельзя, т.к. должны правильно отработать триггеры на update. вопрос больше о том как UPSERT связать с DELETE что-то типа: DELETE WHERE id NOT IN ( INSERT SELECT ... ON CONFLICT DO UPDATE ... RETURNING id); или правильнее с CTE?

я тут просто NOT IN перестал доверять, поскольку переписывание одного запроса на NOT EXISTS ускорило его в сотню раз из-за того что планнер догадался использовать anti join'ы

Есть большая таблица, есть маленькая таблица того же формата и диапазон первичных ключей. Не подскажете как лучше одной операцией заменить все записи в большой таблице принадлежащие диапазону записями из маленькой таблицы, причём просто удалить и добавить нельзя, т.к. должны правильно отработать триггеры на update. вопрос больше о том как UPSERT связать с DELETE что-то типа: DELETE WHERE id NOT IN ( INSERT SELECT ... ON CONFLICT DO UPDATE ... RETURNING id); или правильнее с CTE?

CTE ваше все)

а есть пример для такого паттерна?

with i as (INSERT SELECT ... ON CONFLICT DO UPDATE ... RETURNING id), d as (DELETE WHERE id NOT IN (select id from i) returning *) select count(*) from d;

ага, спасибо!

это на быструю руку

я тут просто NOT IN перестал доверять, поскольку переписывание одного запроса на NOT EXISTS ускорило его в сотню раз из-за того что планнер догадался использовать anti join'ы

Ну и правильно, NOT IN <> NOT EXISTS (и лучше вообще завести привычку не использовать NOT IN).

там если что подправите

With smaltable as ( select data, id from small) update grostable grostable.data = smaltable.data where grostable.id in (select id from smaltable)

Есть большая таблица, есть маленькая таблица того же формата и диапазон первичных ключей. Не подскажете как лучше одной операцией заменить все записи в большой таблице принадлежащие диапазону записями из маленькой таблицы, причём просто удалить и добавить нельзя, т.к. должны правильно отработать триггеры на update. вопрос больше о том как UPSERT связать с DELETE что-то типа: DELETE WHERE id NOT IN ( INSERT SELECT ... ON CONFLICT DO UPDATE ... RETURNING id); или правильнее с CTE?

В чём проблема написать просто большой UPDATE ?

потому что есть добавления и удаления

Ты же написал, что триггера должны сработать... Ну, коли так, так сделай 1 UPDATE, 1 DELETE и 1 INSERT...

Там никаких принципиальных сложностей нет, надо просто взять и написать.

дублировать код в insert и update не хочется, а для delete нужно всё равно список id получить и где-то хранить

я тут просто NOT IN перестал доверять, поскольку переписывание одного запроса на NOT EXISTS ускорило его в сотню раз из-за того что планнер догадался использовать anti join'ы

Зря.

дублировать код в insert и update не хочется, а для delete нужно всё равно список id получить и где-то хранить

Там не будет дублирования кода.

У тебя ТРИ РАЗНЫХ оператора будет. INSERT, UPDATE, DELETE — какое ещё может быть дублирование?

всё что вычисляется нужно будет вычислять и в insert и в update

т.е. писать два раза

Кто нибудь решал проблему репликации изменений в кафку?

всё что вычисляется нужно будет вычислять и в insert и в update

Я ничего не понял... зачем 2 раза? Вы что-то такое делаете? WITH u AS ( UPDATE foo SET something = foo_small.something, something_else = foo_small.something_else FROM foo_small WHERE foo.foo_id = foo_small.foo_id RETURNING foo.foo_id ) DELETE FROM foo WHERE NOT EXISTS (SELECT 1 FROM u WHERE u.foo_id = foo.foo_id); AND <диапазон>;

Да

Вот это только с upsert как раз то что нужно