Database Reference
In-Depth Information
POWER USERS' CLINIC: SYSTEMS WITH MORE THAN ONE DATABASE
Just because you can put a lot of tables into a single database file, no rule says every table has to be
in the same database. In fact, there are lots of good reasons to divide your system across multiple
files.
Chapter 5
mentions a common reason: You might be storing large images or other files in your
database. You can keep these files in an external table so the database file itself isn't so large. Then
you can back up, copy, and email the information about the images without including the images
themselves.
Here are some other reasons to use more than one file:
▪ You can create a database for each kind of layout you need. For example, if you need to track
sales, you can create a database with the tables you need to store the actual data: orders, line
items, customers, shipments, products, and so forth. Your company might use the database in
two ways: Salespeople do data entry (creating and managing orders) and managers do reporting
on those sales (daily, monthly, and quarterly sales reports; trend and promotion analysis; and so
on). To keep your system as simple as possible, you can create these separate layouts as two dis-
tinct databases. Since they share the tables from the central sales database, the reporting data
stays up-to-date as FileMaker processes new sales. But since they're in two databases, the lay-
outs you need for order entry don't get in the way of the reporting layouts, and vice versa. Even
better, it's easier to keep managers from seeing stuff that might confuse them because those
day-to-day task layouts just don't exist in their file.
▪ Expanding on this first reason, one company usually has many database needs. You might have
Sales, Marketing, and Engineering departments in your organization. Each of these departments
has a unique way it deals with data, and the database should match those needs. But the Market-
ing department might be very interested in sales data, and the Sales department needs access to
engineering information. You can create a separate database for each department but share some
tables between systems. This way you get a layout
and
sets of tables that are tailored to each
group, but the important data is shared.
▪ When you can use external table occurrences, you have a very flexible design metaphor. A data-
base—or file—can hold display elements (layouts, scripts, value lists) or data (tables and fields)
or both. Some developers always separate their data and display because it can make it easier to
update the file when major database changes need to happen. In that case, you can replace the
new display file, without needing to import masses of data into a brand-new file. Data separa-
tion is a complex topic and beyond the scope of this topic. To read more about it, perform a
Google search for “FileMaker data separation.”
You can construct the database in almost any way you see fit: one file for each table, all tables in
one file, or tables in logical groupings, all the layouts in one database, or several databases to break
things up. A FileMaker file is a very flexible unit of organization: Use it as you see fit.
You can even give a file reference more than one path. When you do, FileMaker looks for
the file at the first path. If it doesn't find the file, then it tries the second path. The search
