[avihai]

Hey,

In next week we start to deliver a product every week to QA.

The product will developed and maintain in the next months.

I decide to create for each delivery the followinf sql scripts structre:

deliver1:
new- >tables
constraints
fk
indexes
data

upgrade- >tables
constraints
fk
indexes
data


the new will have sql script that create the schema from nothing and upgrade will contain script that upgrade from last version.

I use TOAD in order to get the diff and alter scripts.

My questions:
1. what do you think about the idea above?
2. i have problem that toad give me the data ddl with integrity constraints problem. it is not ordered in order to avoid FK issues. Can you plesae advice?

Any idea or article will be more than welcome.

Thank you

[anacedent]

Whether or not this is a viable approach depends on many unstated details.
Is the s/w eventually going to be installed external to your organization?
What is the expected product life cycle?

I would not want to have to run dozens or hundreds of "change" scripts in order to obtain a complete new copy of the application at any point in the future.

Where does your Code Versioning system come into play?

Your approach will "work" for some definition of "work".

[avihai]

Hopefully this product is going to delivered to the customers in few months.

We need an infrustructre that will support in upgrade and patches without delete the DB.

pathches or updates will be run by the customers IT.

A user that have DB version 2 can update the product to version 11 for example or can install patch that fix his DB.

[anacedent]

It seems reasonable to me that what should be delivered to QA is EXACTLY what will be delivered to the customers.
Otherwise QA will not be testing the exact same collection of files going to the end customers.

[avihai]

Please lets focus on customers.

Does the structre that i write above sound reasonable?
What about the question that i asked about the data DDL FK problem?

Thank you very much!!!!