[Nexialist]

This can be a major pain for larger software projects. At work we have to contend with:

* A database so large that even a minimally empty one cannot be created from scratch in less than 10-15 minutes. This creates problems for CI, integration testing, etc.

* The developers spent a good chunk of the late 90s/2000s writing Oracle PL/SQL code; hundreds of packages and thousands of stored procedures with oodles of business logic.

* We store reports, pdf attachments and other documents etc all in the DB as well.

* Since we put so much stuff on the database, small problems and schema fudges tend to creep in over the years, which makes every customer database a little bit different.

* Oracle licensing can be very unkind and the upper management mandate that we can't use the oracle XE version even in development/testing.

We ended up using a combination of Flyway for schema changes, hand-rolled scripts to apply stored procedures and packages, and we had to roll a database provisioning pool as-a-service for developers, and it's still a massively janky and fragile setup. We really need better tooling for this.

[akbar501]

> * A database so large that even a minimally empty one cannot be created from scratch in less than 10-15 minutes. This creates problems for CI, integration testing, etc.

When we ran into this issue we would take period snapshots of the schema / data dump so that it could be recreated rapidly at a certain point. For example, we would create a DB creation and data insert script at version 2.0, then update scripts would be applied starting at 2.1, 2.2 etc.

[gaius]

A database so large that even a minimally empty one cannot be created from scratch in less than 10-15 minutes. This creates problems for CI, integration testing, etc

You are certainly using the wrong technology then; at a previous job I was easily spinning up 3T Oracle databases in a few minutes using COW clones on the storage array attached to VMs. They were only good for a few hundred M of changes, but that was plenty for testing.

[zzzeek]

> The developers spent a good chunk of the late 90s/2000s writing Oracle PL/SQL code; hundreds of packages and thousands of stored procedures with oodles of business logic.

I've developed a hypothetical approach for versioning of stored procedures within the model described here as part of Alembic, known as "replaceable objects": http://alembic.readthedocs.org/en/latest/cookbook.html#repla...

[jpollock]

Last I looked, Oracle was free for development and test use. Is that no longer the case?

[richmarr]

You see the problem there is that development and test are gateway environments. They lead frequently to other environments such as staging, and production, at which point you find yourself dependent on Oracle's latest stuff and it can be time consuming and expensive to get yourself clean.

Next time you find yourself Jonesing for the latest features and someone offers you dev & test for free, just say no.

[u02sgb]

Actually not the case (and I'm not sure it ever was). We were under this misapprehension for while too.

You're allowed to have a development database to "create one prototype" with a very loose description of what that is. It also "limits the use ... to one person .. and one server". As for testing - "all programs used in a test environment must be licensed".

http://www.oracle.com/us/corporate/pricing/databaselicensing...