Jump to content

Advice from experts before total rebuild of database


Cassetti
 Share

This topic is 5761 days old. Please don't post here. Open a new topic instead.

Recommended Posts

To put the story short, I took over the upkeep and developer for our fmp database. Problem was, from the start, my boss built the database we use as he went. Lots of residual fields and tables and scripts that are still unused.

Its a mess, and the worst kind of mess, one that would take months to fix. Only, we tried for the past few months to have me do what i can. I've reached the point where its so hard for me to fix these old issues because everything is a rats nest on the back end so to speak (Take a newbie to fmp, one with only moderate programming knowledge, and even less experience with user interfaces, and have him build your production database while it is in production! badddd news!)

Anyway, our current databases are all messed up. I've been assigned the task of redoing our entire database using the separation schema: data in one database, and layouts in the other database. This way one can easily build a totally new front end without ever having to disrupt the production environment whatsoever!

What tips does anyone have for taking an existing screwed up database, and rebuilding it from scratch. Not only the backend, but also rebuild the entire front end.

(This database will be used to track inventory, service contracts, contacts, quotes, orders, engineering tickets, etc etc - the usual stuff for a tech company)

Thanks a bunch!!!

Link to comment
Share on other sites

Cassetti:

You've got quite a job in front of you, but also a great opportunity.

You'll be able to fix anything that's broken, streamline anything that's difficult to deal with, and migrate up to FM8 at the same time. Those are the good things. The problem is, you'll be rewriting the whole thing, so you'll be at it for quite some time.

The way I deal with this kind of situation is to take the old system and print out every kind of data you can print out for it - field definitions, value lists, layouts, relationships, and a few sample records, from every file. Then I go through all of those things by hand and mark up what needs to go, what needs to stay, and what needs to be changed.

From those marked-up printouts I can begin building the new system in FileMaker 8. When you get to this point, it becomes easier to move forward than when building a new system from scratch, because so much of what you need to do is right there in front of you.

One very important thing to keep in mind is the migration strategy for the actual data. You must be sure that you will be able to actually get the data into the new system - this is one reason I print out sample data from each file, so that I can see what the data looks like, and see where the data will come from, relative to where, in the new system, it is going to end up.

As I said, it's going to be a long job. Good luck with it.

-Stanley

Link to comment
Share on other sites

Definitely true - I'm very excited about this opportunity to built this database to be functional and fill everyone's needs for a better interface

Very good idea on printing out as much as i can, i'm going to do that when i get to that stage in the process

Thanks for the good advice.

Anyone else have any advice for interfaces? I'm going to take all databases, and design all layouts pretty much from scratch.

Do you guys think that i should install sample databases and view how they organize inventory databases and contact databases?

Link to comment
Share on other sites

This topic is 5761 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.