New Database Structure

Prayder

Registered User.
Local time
Today, 08:48
Joined
Mar 20, 2013
Messages
303
If I am rebuilding a database from an existing database...would it be smarter to import the tables from the exisiting database or just go ahead and build new ones?

When rebuilding a database what would be the most important thing to remember?
 
Why are you rebuilding? Was the structure not supporting your business?
 
I am rebuilding because the databases I have taken over are so convaluted and not working properly.... that I figured it would just be easier.
 
If I am rebuilding a database from an existing database...would it be smarter to import the tables from the exisiting database or just go ahead and build new ones?

When rebuilding a database what would be the most important thing to remember?

The answer to question #1, as you probably expect, is: it depends. Generally, in most cases, you would probably be reusing at least some of the existing table structures. If the changes to the tables are not substantial, ie. adding one or two fields to support some new functiomality, it would probably be better just to import the structure of existing tables. By contrast you would be rebuilding from scratch where the relationships between tables change (, though there might be people who will tell you it is better just cancelling the relationships, and import the existing table structures ). Also, I would recommend building new tables when you are opting for a new naming scheme. There, you will likely have to rebuild your forms as well, as you will likely experience big problems trying to retrofit them to new names.

Question number #2: again that depends on the nature of the rebuild. If you have a database application that has been working well, and the changes are relatively minor, you will likely concentrate on the added functionalities. If however you are rebuilding more substantial pieces, then you need to understand first the changed schema. I would recommend first going over the table relationships in detail, map them out and test everything (new or old !), adding test data only after you have resolved existing issues. The one big thing that I hve learned in the school of hard knocks is : Never leave unresolved issues when building new functional blocks ! Even when you know that processing will likely have to be changed when you add some other module, build only on code that works and works reliably. It is only when unit testing has no outstanding issues that you should add new functional blocks. Otherwise, you might find yourself forever chasing some monster or vice versa.

Good luck !

Best,
J.
 
If the tables are properly normalized, you might as well import them. However, if the database is poorly constructed it is unlikely the tables are correct or that they have good naming standard.
 
How critical is this database to your organization? Just a heads-up before you jump.
Have you built databases before? Or is this first time development? Read that as are you on your own, or do you have support from management/technical people?

You mention you've taken this over, are the previous "handlers" still in the area/company?
Is there any documentation available?

You might want to write up what
not working properly
entails and then highlight steps to correct same. Postpone the decision to rebuild until you quantify the effort involved and the support you can count on.
Then see if rebuild, or adjust... is appropriate; then go with your decision. And, from experience, it's better to have management and those involved in the use of the application participating in some capacity -- testing; answering questions; defining/reviewing rules involved, priority setting.....

Good luck.
 

Users who are viewing this thread

Back
Top Bottom