БД с поддержкой версионирования.

adm-fil
Дата: 06.11.2008 06:13:53
Собственно сабж...
Нужно спроектировать очень простенькую(порядка 10 таблиц) БД, которая будет поддерживать версионирование всех данных.
Версионирование желательно реализовать через ревизии(как в svn), но без чекаутов-чекинов.
Фактически UPDATE и DELETE в такой БД будет запрещен, ни одна из ранее существовавших записей не может быть изменена или удалена.
Моя идея следующая - каждая таблица имеет составной первичный ключ, обязательной частью которого является номер ревизии.

Очень не хочеться изобретать велосипед, может у кого-нибудь есть линки или наработки по этой теме?
Vladimir Sitnikov
Дата: 06.11.2008 07:32:52
adm-fil
Нужно спроектировать очень простенькую(порядка 10 таблиц) БД, которая будет поддерживать версионирование всех данных.
Oracle Total Recall?
adm-fil
Дата: 06.11.2008 08:05:59
Vladimir Sitnikov,
Да,спасибо, это весьма близко к желаемому.
Но версия моего сервера 9,1, а указаная вами технология реализована в 11g.(Обновление сервера БД не предлагать).

Меня интересуют типовые решения, шаблоны.
Elic
Дата: 06.11.2008 08:38:06
RA\/EN
Дата: 06.11.2008 11:52:00
adm-fil
Собственно сабж...
Нужно спроектировать очень простенькую(порядка 10 таблиц) БД, которая будет поддерживать версионирование всех данных.
Версионирование желательно реализовать через ревизии(как в svn), но без чекаутов-чекинов.
Фактически UPDATE и DELETE в такой БД будет запрещен, ни одна из ранее существовавших записей не может быть изменена или удалена.
Моя идея следующая - каждая таблица имеет составной первичный ключ, обязательной частью которого является номер ревизии.

Очень не хочеться изобретать велосипед, может у кого-нибудь есть линки или наработки по этой теме?

Вы себе изощренные грабли сделаете таким подходом - представьте джойн десятка таблиц по ТЕКУЩИМ (последним) версиям.
Выкидывайте триггером при инсерте/апдейте/делите базовой таблицы историческую запись в архив, а можно туда и текущую выкидывать с номером ревизии. Запросы к текущим значениям - по одной таблице, к (потенциально) историческим - по другой.

2Elic:
Workspace Manager - ИМХО, геморройная штука. Гарантия неприкосновености исторических записей непрозрачна...
Elic
Дата: 06.11.2008 11:59:04
RA\/EN
Workspace Manager - ИМХО, геморройная штука.
Я, собственно, не спорю.
adm-fil
Дата: 09.11.2008 15:03:11
Спасибо, товарищи.
В данный момент изучаю Workspace Manager.
По поводу подхода с триггерами - да это интересно. Но, ИМХО, наличие триггеров несколько нарушает чистоту решения. Хотя наверное это то что нужно.
RA\/EN
Дата: 10.11.2008 11:51:16
adm-fil
Спасибо, товарищи.
В данный момент изучаю Workspace Manager.
По поводу подхода с триггерами - да это интересно. Но, ИМХО, наличие триггеров несколько нарушает чистоту решения. Хотя наверное это то что нужно.

Изучайте WM дальше... Окажется, что решение тоже "нечистое"
jjj32
Дата: 10.11.2008 11:54:03
только вот с утра ознакомился :-)
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1171928600346060302
orawish
Дата: 10.11.2008 12:01:14
вот если выкинуть нафик номер ревизии и на его месте нарисовать (одной или двумя) датами отрезок времени, на котором запись актуальна - получите велосипед ~как-у-всех