Помогите решить задачу.

Есть таблица объектов в которой хранятся некие свойства этих объектов: objects(id, a, b, c ,d .. z)
В таблице 1М записей.

С таблицей работают 10К пользователей. Каждый пользователь может произвольно редактировать любые свойства объектов. Однако, эти изменения должны быть локальны. Т.е. каждый пользователь должен видеть (делать выборки и т.д.) только свои изменения + все не измененные объекты - так сказать copy on write.
Реально, пользователь может модифицировать до 1К записей, вряд ли больше.

Как это лучше организовать? Предполагаю, что эта задача вполне типичная. Наверное есть какой-то шаблон решения для такой задачи.

Забыл сказать, пользователь может удалять любые записи. Рзумеется, записи удаляются только в "представлении" конкретного пользователя.

SERG1257Правильно ли я понимаю что остальные видят (читают но не могут изменить) версию до изменений пользователем, а по завершении (commit) работы локальная копия становится доступной остальным?

Нет, не так. Каждый пользователь должен видеть только свои изменения.
Скажем, пользователь поменял объект с id=12345. Он видит измененную версию, все остальные видят оригинальную.

Или, например, два пользователя модифицировали (по разному) объект с id=12345 - каждый видит свою версию. Остальные видят оригинальную версию.

Спасибо за отзывы.
Весьма интересно, подумаю над тригерами.

Таблица, действительно, не единственная и есть связи с другими таблицами.
Конечно, создавать отдельную таблицу для каждого пользователя избыточно. Хотелось бы найти красивое решение :)

У меня есть вариант решения, но мне кажется он несколько громоздким:
1. Таблицу obj расширить: obj(obj_id, orig_obj_id, user_id ...), где
obj_id - собственно id объекта;
orig_obj_id - id оригинала;
user_id - пользователь изменивший объект


2. Создается сопутствующая таблица т.с. скрытых объектов: obj_hidden(obj_id, user_id)
Здесь хранятся obj_id скрытых для данного пользователя объектов.


Для оригинальных объектов в obj.orig_obj_id=null и obj.user_id=null. В случае модификации объекта создается копия. Соответственно, в копии obj.orig_obj_id указывает на оригинал, obj.user_id указывает на пользователя которому принадлежит локальная копия. В таблицу obj_hidden заносится obj_id оригинала.

При удалении пользователем объекта в таблицу obj_hidden просто заносится obj_id. Если пользователь удаляет свой модифицированный объект, в эту таблицу наносится orig_obj_id, а его локальная копия удаляется физически.

Таким образом, выборка obj для пользователя делается по условиям:
obj.user_id=null И obj.obj_id отсутствует в obj_hidden
ИЛИ
obj.user_id=USER

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

SERG1257То есть у вас по любому есть
в какие таблицы вы их засунете это вопрос реализации - вы предложили объединить списки 1 и 2, я предложил объединить списки 2 и 3.

Да, действительно.
Осталось еще view для пользователя оптимально сделать.
Интересно, с точки зрения производительности, какие списки лучше объединить, 1-2 или 2-3.

ОзверинАлекс56,

т.е. мы говорим об истории изменений в разрезе пользователя просто? и все?

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