We have a pretty large database that uses temporal tables. For a development subset we are not interested in the whole history.
When subsetting, it's important that the samples from the history tables are sequential and have no gaps. So a random subset will not provide the data needed to test the full behaviour of the application accessing that DB.
It would be necessary to provide a "sequential" subset, using one or more columns for ordering (including asc/desc option) and specifying the size of the subset. In this particular case, a static size (in number of rows) would be better than a percentage.
A nice-to-have would be to match the subset on a table-name pattern. All the history tables live in their own schema so using a pattern like history.* would be nice as it would dynamically adapt to DB changes.
We have a pretty large database that uses temporal tables. For a development subset we are not interested in the whole history.
When subsetting, it's important that the samples from the history tables are sequential and have no gaps. So a random subset will not provide the data needed to test the full behaviour of the application accessing that DB.
It would be necessary to provide a "sequential" subset, using one or more columns for ordering (including asc/desc option) and specifying the size of the subset. In this particular case, a static size (in number of rows) would be better than a percentage.
A nice-to-have would be to match the subset on a table-name pattern. All the history tables live in their own schema so using a pattern like
history.*would be nice as it would dynamically adapt to DB changes.