Hello everyone, this is a little philosophical in nature.

In my company, we currently have about eight files that were created to do different things (print reports, current order status, shipping tags, envelopes, etc). I just joined the company and after looking at the files there is a ton of duplication between the information and re-entry of the same data.

I feel that it would be possible to use the most comprehensive file that has most of the information and just create different layouts and scripts to get all of our business functions done with the least amount of duplication, thus eliminating the need for all of the other files.

What would be your concerns and interests when creating this master file? Is there advantages to having eight files or just one? Any strategies to offer?

Edited November 8, 200619 yr by Guest

Hi raouls:

... after looking at the files there is a ton of duplication between the information and re-entry of the same data.

Sounds like my last six projects, and the 14 before that, and.... seems for any operation that has pre-FM7 databases, this is often the situation. Sometimes it's design dictated duplication to some degree, but more frequently it's the result of an author's skills.

Is there advantages to having eight files or just one?

Having a single file is pretty convenient, but there are enough considerations that we've had some popular threads in FMForums on this very topic.

But if you're talking about reducing the number of tables and building a solid relational structure that takes advantage of data normalization, then you're cookin' with gas!

What would be your concerns and interests when creating this master file?... Any strategies to offer?

• Starting with a brand new file, void of any hint of file corruption.

• Consulting with users to find out what they like, don't like, need, etc.

• Being prepared for the possibility that the solution will need to do more than the current system. (Once you consult with users, you'll start to have a lot of ideas what else the solution could/should do. It can be a little maddening, but if you like puzzles and logic, you'll love this part of the project.)

• Trying my very best to plan the solution's architecture in such a way that it can expand with future demand.

• Maintaining the current system in good, working order. It will have to carry the company until the new solution is ready for launch.

I don't think you're being too philosophical; I think you're asking great questions!

I'd suggest you study up on relational design first, before attempting to consolidate files. It sounds like the redundancy in your files could be eliminated, but you should really make sure you understand how to identify the various entities and relationships that become apparent when working out the business needs, so they can be modeled in an ER Diagram.

It's equally important to have a good understanding of how FileMaker works with tables and relationships, so you can translate the ER Diagram into tables, table occurences, and relationships.

This may just require some book reading, if you learn that way, or FileMaker training classes.