Database

15-Feb-07 11:03

I'm curios what's the best option to clear a database that contains a large number of tables?
Do we need to pick every table and issue delete statements (except those that have cascade rule set)?
Does anybody had any similar issue?

company, work and everything else @ netis

-Dr_X-15-Feb-07 11:06

-Dr_X-

15-Feb-07 11:06

Another way is simply to extract the schema and create a new database from it.

I firmly believe that any man's finest hour, the greatest fulfillment of all that he holds dear, is that moment when he has worked his heart out in a good cause and lies exhausted on the field of battle - victorious.
Vince Lombardi (1913-1970)

Member 9615-Feb-07 11:12

15-Feb-07 11:12

There are three ways I would approach this:
The cleanest and fastest way if it's a database that contains a lot of data is to issue a drop statement against the entire database. I.E. remove the database completely and then recreate it.
The advantage of this is that it's clean and fast if you have to empty a database that already has a lot of data in it. The disadvantage is that you have to recreate the database from code, but it's usually a good idea to have code do that in any case which makes installations etc easier.

The second way depends on the database server itself many SQL servers have some kind of syntax for quickly emptying tables. In MS SQL server you can use something like "truncate table" (oracle too I think) it will delete much faster because it won't log each row deletion, however it will still respect referential integrity so if you have foreign keys etc you will have to either a) Be careful what order you remove the tables in always removing the ones at the outermost "branches" of the relationships first or b) drop the relationship then recreate it after you've truncated.

The third way is to issue delete statements against tables with the same caveats about referential integrity as the second way, but it's much slower than using truncate table.

In my own software I use the second *and* third way because for the areas that need to clean out the datbase they need to keep some of the data in some of the tables. And I have to support Firebird as well as mssql which doesn't have a truncate table command. If this weren't the case I'd go with option 1 every time, nothing is faster or cleaner than that.

Zoltan Balazs15-Feb-07 11:18

15-Feb-07 11:18

I'm using Firebird and I also need to keep (in some cases) data in some of the tables.
I did go with the third option, however it is just getting more and more complicated Frown | :(

(and I don't know if it's a good idea to reset the generators also)

company, work and everything else @ netis

Member 9615-Feb-07 11:29

15-Feb-07 11:29

Resetting the generators depends on a lot of things:
Let's say you are using them for a number that is visible to the user of the program and may print on reports etc. If they erase the data and start again it's possible that they might have old documents with the old number on them, in which case it's a bad idea to reset it as it won't be unique.

If they are only used internally and not to any of the unerased data then it's not a problem

I don't use generators for unique record ID's in Firebird because I support more than one type of database and my app generates it's own unique GUID values for records so in Firebird I just use the GUID's instead.

This stuff is always complicated, I have hundreds of tables in my app with some linked 4 deep.
If it was easy they wouldn't need anyone to write software. Wink | ;)

Zoltan Balazs15-Feb-07 11:33

15-Feb-07 11:33

John Cardinal wrote:
This stuff is always complicated, I have hundreds of tables in my app with some linked 4 deep.
If it was easy they wouldn't need anyone to write software.

Exactly

I guess I'm going on with the 3rd option Wink | ;)

company, work and everything else @ netis

Member 9615-Feb-07 11:39

15-Feb-07 11:39

For my code for the 3rd option I just made a helper method to delete the tables with the option of passing a generic List of ID's, then I can just pass that method a table name, it takes care of emptying it and optionally a list with one or more id's which it then constructs into a different format delete to keep the records id'd.

I know it's messy and not really programming to have to keep track of and work with the database schema, but there's no getting around it. You really do have to take the time to determine the correct order to delete those tables and always keep it in mind when adding new tables etc. It's easy to add a new table or feature to a program and then find out later from the end user that the erase database function is now broken. It helps to put it all in one place, the code that creates the schema updates and the code that does the table deletion and also make sure you have a schema level version number in your database itself so that you can handle properly database schema versionsing between your code and the database.

This means you can then put delete and table creation blocks in regions flagged with the db schema version number.

It means nothing at first release, but it's critical down the road for updates.

Zoltan Balazs15-Feb-07 11:42

15-Feb-07 11:42

John Cardinal wrote:
a schema level version number

I have, but I store only the last version of the DB.

John Cardinal wrote:
It means nothing at first release, but it's critical down the road for updates.

story of my life Laugh | :laugh:

...

company, work and everything else @ netis

Member 9615-Feb-07 11:47

15-Feb-07 11:47

Zoltan Balazs wrote:
I have, but I store only the last version of the DB.

That's fine, that's what I do. When my user logs in, the required db schema set in my app is checked against the db's stored schema number.

If the db has a higher number my app exits with a warning that it's out of date.

If the db has a lower number my app triggers a schema update that goes through a big switch statement and executes each newer schema level update until it matches the program's required version.

Zoltan Balazs15-Feb-07 11:52