База данных, интегрированная с системой контроля версий — существует ли такое? Чтобы любое изменение в базе создавало новую ревизию, и можно было откатиться на любое состояние в прошлом. Чтобы можно было отрастить ветку от нынешнего или любого прошлого состояния, и переключаться между ветками. Чтобы можно было сджойниться с таблицей в другой ветке и ревизии. Чтобы можно было делать диффы и мерджи. Чтобы можно было искать не только по тем данным, которые есть сейчас, но и тем, которые были в предыдущих ревизиях и/или в других ветках.

Здравствуйте, nikov, Вы писали:

N>База данных, интегрированная с системой контроля версий — существует ли такое? Чтобы любое изменение в базе создавало новую ревизию, и можно было откатиться на любое состояние в прошлом. Чтобы можно было отрастить ветку от нынешнего или любого прошлого состояния, и переключаться между ветками. Чтобы можно было сджойниться с таблицей в другой ветке и ревизии. Чтобы можно было делать диффы и мерджи. Чтобы можно было искать не только по тем данным, которые есть сейчас, но и тем, которые были в предыдущих ревизиях и/или в других ветках.

Ну, в CouchDB новая версия документа — это именно новая версия со своим номером ревизии и возможностью откатиться назад

Здравствуйте, Mamut, Вы писали:

M>Ну, в CouchDB новая версия документа — это именно новая версия со своим номером ревизии и возможностью откатиться назад

Меня главным образом интересуют реляционные БД.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Mamut, Вы писали:

M>>Ну, в CouchDB новая версия документа — это именно новая версия со своим номером ревизии и возможностью откатиться назад

N>Меня главным образом интересуют реляционные БД.

Вроде к MS SQL был плагин к VSS.

Здравствуйте, nikov, Вы писали:

N>База данных, интегрированная с системой контроля версий — существует ли такое? Чтобы любое изменение в базе создавало новую ревизию, и можно было откатиться на любое состояние в прошлом. Чтобы можно было отрастить ветку от нынешнего или любого прошлого состояния, и переключаться между ветками. Чтобы можно было сджойниться с таблицей в другой ветке и ревизии. Чтобы можно было делать диффы и мерджи. Чтобы можно было искать не только по тем данным, которые есть сейчас, но и тем, которые были в предыдущих ревизиях и/или в других ветках.
Боюсь. Откатиться до любой точки назад, да, можно в любой внятной СУБД, правда не так просто как в VCS, а вот уже с ветками, мерджами и темпоральными запросами — не судьба.
Тут и проблемы связанные с отсутствием идентификаторов у кортежей в реляционке, и непонятно что делать при изменении схемы, и оптимизатору работать уже не так просто. Опять-таки под конкретную задачу такое можно сделать уже поверх обычной БД, например тот же TFS вполне себе использует MSSQL в качестве хранилища.

Здравствуйте, IB, Вы писали:

IB>Откатиться до любой точки назад, да, можно в любой внятной СУБД, правда не так просто как в VCS,

Ты имеешь в виду: поднять старый бекап и накатить лог? Или появились более простые и гибкие подходы? Хотелось бы прямо в запросе обратиться к состоянию какой-то таблицы в прошлом.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, IB, Вы писали:

IB>>Откатиться до любой точки назад, да, можно в любой внятной СУБД, правда не так просто как в VCS,

N>Ты имеешь в виду: поднять старый бекап и накатить лог? Или появились более простые и гибкие подходы? Хотелось бы прямо в запросе обратиться к состоянию какой-то таблицы в прошлом.

У оракла есть Flashback, но это по ходу заметно меньше того, что ты хочешь.

Здравствуйте, nikov, Вы писали:

N>Ты имеешь в виду: поднять старый бекап и накатить лог?
Именно.

N>Или появились более простые и гибкие подходы? Хотелось бы прямо в запросе обратиться к состоянию какой-то таблицы в прошлом.
У оракла есть Flashback запросы, но AFAIK на практике это вообще малоприменимо и используется в основном для административных целей.

Здравствуйте, nikov, Вы писали:

Такие вещи реализуют обычно на прикладном уровне.

Здравствуйте, Курилка, Вы писали:

К>У оракла есть Flashback, но это по ходу заметно меньше того, что ты хочешь.

А как сейчас обстоит дело с метазапросами наподобие:
"Показать список всех запросов за последнюю неделю, которые затрагивали таблицу AAA и вернули больше 1000 записей."
"Показать список всех запросов за последнюю неделю, которые затрагивали таблицу BBB и заняли больше 3 секунд процессорного времени."
"В каких 10 таблицах число записей увеличилось сильнее всего за последний месяц."

Много ли надо сделать телодвижений, чтобы можно было легко получать ответы на подобные запросы?

Здравствуйте, AndrewVK, Вы писали:

AVK>Такие вещи реализуют обычно на прикладном уровне.

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

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Курилка, Вы писали:

К>>У оракла есть Flashback, но это по ходу заметно меньше того, что ты хочешь.

N>А как сейчас обстоит дело с метазапросами наподобие:
N>"Показать список всех запросов за последнюю неделю, которые затрагивали таблицу AAA и вернули больше 1000 записей."
N>"Показать список всех запросов за последнюю неделю, которые затрагивали таблицу BBB и заняли больше 3 секунд процессорного времени."
N>"В каких 10 таблицах число записей увеличилось сильнее всего за последний месяц."

N>Много ли надо сделать телодвижений, чтобы можно было легко получать ответы на подобные запросы?

Тут не помощник — сам с ораклом работал года 2 назад, да и без особых наворотов.
А сейчас вообще с MySQL ковыряюсь

Здравствуйте, nikov, Вы писали:

N>"Показать список всех запросов за последнюю неделю, которые затрагивали таблицу AAA и вернули больше 1000 записей."
MSSQL 2005 и больше — можно что-то пободное (точно не знаю, давно не смотрел) через системные вьюшки, только не по таблицам, а по индексам.
То есть какая-то статистика по использованию индексов в принципе доступна.

N>"Показать список всех запросов за последнюю неделю, которые затрагивали таблицу BBB и заняли больше 3 секунд процессорного времени."
При поднятом профайлере за последнюю неделю — нет проблем (ну и предыдущее тоже).

N>"В каких 10 таблицах число записей увеличилось сильнее всего за последний месяц."
Напрямую вряд ли, но применив какую-нибудь эвристику наверняка можно.

N>Много ли надо сделать телодвижений, чтобы можно было легко получать ответы на подобные запросы?
Основная засада — наличие запущенного профайлера, который собирает статистику, с его помощю достать можно практически все, но он заметно снижает производительность. Многое можно достать и без профайлера, но это сложнее, зависит от конкретного сценария.