AnsweredAssumed Answered

One Comapny - Three Divisons - Multiple databases?

Question asked by AJ135 on Dec 12, 2012
Latest reply on Dec 22, 2012 by philmodjunk

Like • Show 0 Likes0
Comment • 8

Title

Post

I am a new FM user, have wanted to do this for a long time, but felt it was too big a job....my thinking has changed and i am ready for the plunge!

BACKGROUND

We are a small company divided into three seperate divison (each selling a different product or Service). We have 11 Associates, each one of them can interact with either of the divisons at any time. Many of our Clients will be connected to either 1, 2 or all 3 divisons. Two of the divisions have inventory with pictures etc that we would like to include in our database. The third divison is basically a service orietated divison.

QUESTIONS

what is the best way to setup the database(s)?
should we make a database for each diviosn and then have relationshipds connecting them?
How big can a database be?

Any advice in the initial building of teh database(s) would be greatly appreciated.....

Thanks

Andrew

No one else has this question

Outcomes

philmodjunk Dec 12, 2012 9:22 AM

1) there is no one "best way" but do keep your design to a single database shared by all departments. Your post clearly describes data that needs to be available to more than one such department. Note that a "database" can consist of one database file with many tables or can be made of many files. There are trade offs inherent to each approach. The data modeling--deciding how many tables to define and what fields should be defined in each, is critical to getting a good database design and requires knowledge not available to people responding to your post.

3) you are more likely to run out of hard drive space before your database will be "too big" for fileamaker, but very large data sets (more than 10,000 records say), require carefull handling and there does come a point (with many more records than that) where other database systems better designed to handle such large amounts of data should be evaluated as a better option.

Actions

AJ135 Dec 12, 2012 9:27 AM

Thanks for your response

So if I am understanding things correctly, the 'best' approach is to have one database, different tables/files covering the range of information and that would work best.

Are you also saying that it is too big a project for a newbie?

Cheers

Andrew

Actions

philmodjunk Dec 12, 2012 10:05 AM

I cannot judge from here whether or not this project is too big for you. I don't know your capabilities and I don't have a full understanding of the scope of your project.

I can suggest that you start small, Saving Sequential Back Ups During Development, add new features, modules a bit at a time with lots of testing and be prepared to modify your design--even if you have to discard days of work, if you figure out a better approach to use after the fact.

And i can also strongly, recommend that you acquire FileMaker Advanced if you have not already done so. The script debugger and data viewer tools alone will save you many hours of effort when a part of your database doesn't work as expected.

Actions

AJ135 Dec 12, 2012 10:58 AM

Thank you very much, I wll take all that into consideration

Cheers for your help

Andrew

Actions

RickWhitelaw Dec 12, 2012 1:31 PM

Phil,

Did you mean 10,000,000 records perhaps? Or 100m? 10,000 seems pretty small"

Actions

philmodjunk Dec 12, 2012 4:13 PM

Any number we can use is pretty vague as there are many more variables than just the total number of records.

Note that I am NOT saying you should change database apps if you have more than 10,000 records in a table. What I AM saying is that by the time your record counts start getting that large, sorts and finds on unstored/unindexed fields, aggregate/summary value calcs over the entire table start generating noticeable delays and you have start employing scripts and other tools to help avoid/minimize those delays. I have one File where a LineItems table exceeds 2 million total records. It works just fine, but there are certain reports in that file where I am very careful not to do a Show All Records during regular business hours...

Actions

TKnTexas Dec 21, 2012 7:58 PM

In reading over the responses, one point I would consider. It is the question of access to the databases. Are the divisions geographically separated? If so would response time be improved if the divisions are accessing locally and not remotely?

Actions

philmodjunk Dec 22, 2012 10:27 AM

A very good point. My assumption had been departments all on the same LAN, but that is purely an assumption.

Actions

8 Replies

philmodjunk Dec 12, 2012 9:22 AM
Mark Correct
Correct Answer
1) there is no one "best way" but do keep your design to a single database shared by all departments. Your post clearly describes data that needs to be available to more than one such department. Note that a "database" can consist of one database file with many tables or can be made of many files. There are trade offs inherent to each approach. The data modeling--deciding how many tables to define and what fields should be defined in each, is critical to getting a good database design and requires knowledge not available to people responding to your post.

3) you are more likely to run out of hard drive space before your database will be "too big" for fileamaker, but very large data sets (more than 10,000 records say), require carefull handling and there does come a point (with many more records than that) where other database systems better designed to handle such large amounts of data should be evaluated as a better option.
Like • Show 0 Likes0
Actions
AJ135 Dec 12, 2012 9:27 AM
Mark Correct
Correct Answer
     Thanks for your response



     So if I am understanding things correctly, the 'best' approach is to have one database, different tables/files covering the range of information and that would work best.

     Are you also saying that it is too big a project for a newbie?

     Cheers

     Andrew
Like • Show 0 Likes0
Actions
philmodjunk Dec 12, 2012 10:05 AM
Mark Correct
Correct Answer
     I cannot judge from here whether or not this project is too big for you. I don't know your capabilities and I don't have a full understanding of the scope of your project.

     I can suggest that you start small, Saving Sequential Back Ups During Development, add new features, modules a bit at a time with lots of testing and be prepared to modify your design--even if you have to discard days of work, if you figure out a better approach to use after the fact.

     And i can also strongly, recommend that you acquire FileMaker Advanced if you have not already done so. The script debugger and data viewer tools alone will save you many hours of effort when a part of your database doesn't work as expected.
Like • Show 0 Likes0
Actions
AJ135 Dec 12, 2012 10:58 AM
Mark Correct
Correct Answer
     Thank you very much, I wll take all that into consideration



     Cheers for your help



     Andrew
Like • Show 0 Likes0
Actions
RickWhitelaw Dec 12, 2012 1:31 PM
Mark Correct
Correct Answer
     Phil,



     Did you mean 10,000,000 records perhaps? Or 100m? 10,000 seems pretty small"

     RW
Like • Show 0 Likes0
Actions
philmodjunk Dec 12, 2012 4:13 PM
Mark Correct
Correct Answer
Any number we can use is pretty vague as there are many more variables than just the total number of records.

Note that I am NOT saying you should change database apps if you have more than 10,000 records in a table. What I AM saying is that by the time your record counts start getting that large, sorts and finds on unstored/unindexed fields, aggregate/summary value calcs over the entire table start generating noticeable delays and you have start employing scripts and other tools to help avoid/minimize those delays. I have one File where a LineItems table exceeds 2 million total records. It works just fine, but there are certain reports in that file where I am very careful not to do a Show All Records during regular business hours...
Like • Show 0 Likes0
Actions
TKnTexas Dec 21, 2012 7:58 PM
Mark Correct
Correct Answer
In reading over the responses, one point I would consider. It is the question of access to the databases. Are the divisions geographically separated? If so would response time be improved if the divisions are accessing locally and not remotely?
Like • Show 0 Likes0
Actions
philmodjunk Dec 22, 2012 10:27 AM
Mark Correct
Correct Answer
A very good point. My assumption had been departments all on the same LAN, but that is purely an assumption.
Like • Show 0 Likes0
Actions

One Comapny - Three Divisons - Multiple databases?

Title

Post

Outcomes

Related Content

Recommended Content