mazzyесли у нас корпоративное приложение с рабочей базой на MS SQL в несколько терабайт, то возникает вопрос как сделать корректные тестовые данные? генерить собственную маленькую AdventureWorks - тот еще проект с непонятной трудоемкостью и непонятной корректностью.

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

А для теста лучше восстанавливать рабочую БД, потому что, несмотря на размер БД, её бакап всё равно нужно где то проверять путём восстановления.
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.

КритикalexeyvgПритом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.
Это в теории. А на практике с таким подходом потеряете кучу времени разработчиков, цена простоя за год выйдет подороже, чем хороший массив.Я же не против хорошего массива, но даже в хорошем массиве стоимость терабайта небольшая, если хранилище проектировалось для объёма, а не для скорости.

Гулин Федорalexeyvgпропущено...
Для dev можно генерить синтетические данные, либо брать небольшую вырезку из рабочих данных.

А для теста лучше восстанавливать рабочую БД, потому что, несмотря на размер БД, её бакап всё равно нужно где то проверять путём восстановления.
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.я правильно понимаю что для DEv -
это РУЧНОЙ скрипт ?
ну ведь там FK-s - какие то таблицы целиком тянуть
какие то можно за месяц и т.д и т.п
фактически такой полноценный ETL
к-й будет устаревать к тому же с появлением новых таблиц ?Да, правильно.
Понятно же, что никакая разработанная изготовителем БД логика не может учесть бизнес-логику ваших данных, а получить обрезанную версию БД без учёта бизнес-логики данных невозможно.

Соответственно, остаётся либо создавать ETL-решение для частичного переноса данных (возможно, с деперсонализацией и искажениями цифр), или генерить тестовые данные (для чего в принипе существуют всякие решения, но они тоже не делают всё "одной кнопкой")

Или, как вариант, использовать в качестве дева копию продакшен базы (как и для теста), что, разумеется несравнимо дешевле, потому что десяток терабайт даже на SSD-массиве не сравнить по стоимости с полноценным проектом.

КритикВ dev-среде можно многим пренебречь, в том числе и FKЭто да, но лучше делать дев полноценной копией продакшена (по модели и логике данных), что бы понизить стоимость разработки.