Я рассматриваю реализацию версионирования объектов с дополнительным поворотом необходимости иметь как живые, так и черновые объекты, и мог бы использовать идеи, полученные от кого-то из них, поскольку я начинаю задумываться, возможно ли это вообще без ужасные хаки.
Я расскажу об этом в статьях с тегами для примера, но мой вариант использования немного более общий (включает медленно меняющиеся размеры - http://en.wikipedia.org/wiki/Slowly_changing_dimension).
Предположим, у вас есть таблица сообщений, таблица тегов и таблица post2tag:
posts (
id
)
tags (
id
)
post2tag (
post_id fkey posts(id),
tag_id fkey tags(id)
)
Мне нужна пара вещей:
- Возможность точно показать, как выглядело сообщение в произвольный момент времени, в том числе для удаленных строк.
- Следите за тем, кто что редактирует, для полного аудита.
- Требуется набор материализованных представлений («живых» таблиц) для сохранения ссылочной целостности (т. Е. Регистрация должна быть прозрачной для разработчиков).
- Должен быть соответственно быстрым для живых и последних черновых строк.
- Возможность иметь черновик сообщения вместе с живым сообщением.
Я изучал различные варианты. Пока что лучшее, что я придумал (без точек # 4 / # 5), немного похоже на гибридную установку типа 6 SCD, но вместо текущего логического значения есть материализованное представление для текущей строки. Для всех намерений и целей это выглядит так:
posts (
id pkey,
public,
created_at,
updated_at,
updated_by
)
post_revs (
id,
rev pkey,
public,
created_at,
created_by,
deleted_at
)
tags (
id pkey,
public,
created_at,
updated_at,
updated_by
)
tag_revs (
id,
public,
rev pkey,
created_at,
created_by,
deleted_at
)
post2tag (
post_id fkey posts(id),
tag_id fkey tags(id),
public,
created_at,
updated_at,
updated_by
)
post2tag_revs (
post_id,
tag_id,
post_rev fkey post_revs(rev), -- the rev when the relation started
tag_rev fkey tag_revs(rev), -- the rev when the relation started
public,
created_at,
created_by,
deleted_at,
pkey (post_rev, tag_rev)
)
Я использую pg_temporal для поддержания индексов по периоду (создал_, удален_). И я синхронизирую различные таблицы с помощью триггеров. Яда, яда, яда ... Я создал триггеры, которые позволяют отменить редактирование сообщений / тегов таким образом, чтобы черновик сохранялся в оборотах без публикации. Отлично работает.
За исключением , когда мне нужно беспокоиться о связях, связанных с черновиками, на post2tag. В этом случае весь ад вырвется на свободу, и это намекает мне на то, что у меня там какая-то проблема с дизайном. Но у меня заканчиваются идеи ...
Я рассмотрел вопрос о введении дублирования данных (то есть n строк post2tag, введенных для каждой черновой версии). Это работает, но, как правило, медленнее, чем хотелось бы.
Я подумал о введении таблиц черновиков для «последнего черновика», но это быстро становится очень и очень уродливым.
Я рассмотрел все виды флагов ...
Итак, вопрос: существует ли общепринятый способ управления живыми и неживыми строками в среде с управлением версиями строк? А если нет, то что вы пробовали и были достаточно успешны?