Всем привет.

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

Ситуация следующая : в БД ведется учет по нескольким организациям. Технически это сделано в виде наличия поля - FK на таблицу организаций. Но не во всех таблицах есть поле Company - деление может осуществляться не явно через связи с другими таблицами. Более того некоторые таблицы - справочники делятся на версии (это когда у нескольких организаций - одна и та же справочная информация). Кто работал с ПП "Парус" - знает о чем я.

Так вот, возможный заказчик хочет чтобы у каждой организации была своя тестовая БД и с данными только своей организации.

Я вижу тут три варианта :
1. Разработка мозговыносящих скриптов и экспорт через exp. Кол-во таблиц и их размер - огромное.
2. Data Subsetting. Стоимость на 1 процессор 11500$+поддержка 2530$ в год. И будет ли ощутимый выигрыш в скорости и простоте сопровождения?
3. Ничего делать не надо. Надо просто сделать одну - две тестовые базы(полных копий промышленной) для всех организаций.

3 вариант не устраивает возможного заказчика.

heroin2,

При 3 варианте подразумеваетя что пользователи работают только в боевой базе. О существовании теста они не должны знать.
У нас у самих сейчас одна тестовая база для всех организаций. Т.е. все разработки идут в ней. При огромном числе разработчиков (подразумевается у каждой организации своя группа разработки) помогают системы контроля версий (типа SVN).

Так вот получается, что конфидециальную информацию других организаций (например начисление з/п работникам предприятия) нужно скрыть от разработчиков, тестировщиков и прочих аналитиков. Этого можно достичь во время экспорта боевой базы разными способами. Но проблему это все равно не решает - кто -то должен переносить ПО из тестовой базы в боевую. В любом случае будут люди, которые знают все обо всем. В этом случае с точки зрения разработки не вижу особой разницы между разработкой в общей тестовой базе и в отдельной (своей) базе.

Про on delete cascade сразу нет :).