How and When to Use Multiple Files

 <  Day Day Up  >  

The preceding section showed the mechanics of creating a FileMaker system that uses tables from different files. It didn't say much about the reasons why, in general, you might want to do such a thing. We offered the example of needing to work with a pre-existing file "owned" by someone else. This is certainly a relevant case, but there are also reasons why you might choose to build your own systems with multiple files from the start. This section looks over some of the major reasons for using multiple files in a single database solution.

Working with Converted Files

FileMaker 7 represents a very new way of building FileMaker databases. The differences between FileMaker 7 and previous versions are significant enough that converting a system from a previous version to 7 is not quite the easy, nearly transparent process that conversions between different versions of the product have been in the past.

For greater detail on the conversion process, see Chapter 18, "Converting Systems from Previous Versions of FileMaker Pro," p. 507 .


graphics/new_icon.jpg

In previous versions of FileMaker, each database table was represented by a single physical disk file. A ten-table system would use ten different FileMaker files. In FileMaker 7, if you build that ten-table system from scratch, you could choose to put all ten tables into a single physical file. But if you're converting that system from, say, FileMaker 6 to FileMaker 7, you won't have that option. The conversion process cannot roll separate files together into a single new FileMaker 7 file. Your ten-file (that is, ten-table) FileMaker 6 system becomes a ten-file FileMaker 7 system as well. The conversion process brings forward all the appropriate file references into each of the new FileMaker 7 files, and populates the Relationships Graphs of each file appropriately, but structurally you'll still have a set of ten interlocking files, just as you did before. From that point, of course, you might be able to start rolling the different tables together, but the process is largely a manual one.


Any system converted from previous versions of FileMaker is sure to have a large number of external file references. Many of these may be to the same file, but in different forms (with different directory paths, for example). The new system will probably work perfectly well like this. And if it's working, you're likely to leave it alone. At most you may consider adding any new tables into existing files, when and if new tables become necessary.

NOTE

The presence of multiple redundant file paths in a single file reference is characteristic of files converted from FileMaker 6 and earlier to FileMaker 7. In previous versions, if you worked with a file in multiple places over time, many or all of those places might end up in the file path list. Because FileMaker needs to search the entire file reference, item by item, all the unused file paths can cause significant slowdown in opening files.


For more information on this problem, and on approaches to solving it, see "Fix File References," p. 518 .


Separation of a System into Modules

FileMaker 7 makes it possible, even tempting, to put all the tables for a database system into a single file and be done with it. But is that always the best choice? Well, there are still several reasons to suggest that breaking things into multiple files may sometimes be a more suitable choice. The sections that follow examine a number of potential benefits to using multiple tables. We're not presuming anything about how , exactly, you might choose to split your tables up. There are a few possibilities. If your system falls cleanly into several different "modules," for example (let's say Accounting, Orders, and Inventory), it may make sense to take the tables that comprise each module and group each set in its own file. You may also want to split your system into a file of data tables and another file dedicated to interface layouts and application logic such as scripts; this possibility is discussed later in this chapter in "Separation of Data and Application Logic."

Ease of Shared Development

FileMaker has always been a great Rapid Application Development (RAD) tool, but the product has tended to retain an emphasis on the single developer. It's often been challenging for multiple people to work on the same FileMaker system simultaneously without getting in each other's way. In previous versions of the product, only one person could open the ScriptMaker at a time, and only one person could access the Define Fields dialog at once.

graphics/new_icon.jpg

Things are much improved in FileMaker 7. Anyone with sufficient privileges can open the ScriptMaker. If others have ScriptMaker open as well, you'll be inhibited from editing only any scripts they have open, and any subscripts called by those scripts. But in other ways FileMaker 7 exacerbates the earlier problem, in that scripts in FileMaker 7 can span multiple tables within a single file, aggregating together scripts that would have been separated into different files in earlier versions. The more tables you group into a single file, the more likely it may be that multiple developers will interfere with each other when editing scripts.


Things are a bit tougher with the database definition tools. In another advance from previous versions, multiple developers can open the Define Database dialog at once. But only one at a time can be "in control" of the database definition. The others can view any aspect of the structure, but cannot change it.

So if you expect you'll often have more than one person making script or database definition changes inside your system, it may make sense to try to separate your tables into groups and put each group in its own file to minimize the chances of developers getting in each other's way.

Ease of Maintenance

Every database system needs maintenance. Files become fragmented , which makes access to them slower. Lost space needs to be reclaimed; indexes need to be optimized. FileMaker is no different. It's a good idea to perform periodic file maintenance on your FileMaker files.

For a discussion of file maintenance, see "File Maintenance and Recovery," p. 503 .


One thing to consider is that the larger your file, the longer it takes to perform this periodic maintenance. The same is true for other maintenance tasks , such as backing up. If your system is particularly large, say in the hundreds of megabytes or into the gigabyte range, your backups will take a long time to run. This may not be a problem if you run your backups at night, but in many mission-critical systems the data is backed up periodically during the day, sometimes as often as hourly. If all your tables are in a single file, your choices are to back up all, or nothing. There's no way to back up only a few tables from a single file. Suppose further that this system had one massive table of fairly static data, which changed on the order of only once a week, as well as many smaller tables of critical, highly changeable data. In the best of all worlds you'd back the huge table up daily or weekly, the smaller ones perhaps as often as hourly. If all the tables are in one file, you're out of luck. Each backup has to copy the single massive table again, even though it's unlikely to have changed.

In the worst case, consider the problem of file recovery. In rare circumstances, a FileMaker file can become damaged or unusable due to a crash. If all your tables and data are in that one file, the consequences of a crash are potentially catastrophic. One bad event can in theory compromise your entire system.

Even if the worst doesn't happen, you may still need to run a recovery on such a file. As with maintenance and backups, the time it takes to recover the file is in proportion to its size . And you need to recover everything ”all the tables ”even if the massive ones were undamaged and only the little ones were damaged in some way. Had the tables been separated into additional files, the consequences of a crash could have been mitigated.

None of this is to suggest that you should go back to the one-file-per-table model of previous versions, necessarily . It does mean that you should think carefully about how your database is going to be used, and whether there will be wide variation in size or usage pattern among tables. If such differences exist and can be predicted , it may be worthwhile to isolate certain tables in their own file or files.

Separation of Data and Application Logic

In FileMaker 7, as in previous versions, data and application logic are mixed together in a single file. Not only does a physical file contain a system's data (the "database" portion of things), but also all the scripts, layouts, value lists, and the like that make up the " user application" portion of things. After a system has been rolled out and is in use, if you want to continue to make changes to it, you have a limited range of choices.

One possibility is to work directly on the running copy. FileMaker permits this; you can edit scripts, add layouts, even add entire tables to a running system. Still, just because you can doesn't mean you should. What if you make a mistake? (They do happen from time to time ”in fact we devote an entire chapter to avoiding and repairing them.) That mistake will impact users who are probably trying to get work done. It may be merely annoying, or it may be catastrophic. If the changes are small and you know what you're doing, you may be fine making the changes on-line, so to speak. For more extensive changes, it's not a great idea.

Another possibility is to work on a copy of the system. Make all your changes, test them every which way, and when they're all ready, integrate them into the current live system. But here's where the data-and-logic problem rears its head. You can't just replace the existing production files with your development copy ”the production files almost certainly contain a different data set. And there's no convenient way to merge your structural changes with the data in the live copy. In previous versions of FileMaker, you needed to shut down the live file and import its data into your development copy. Depending on the size of the data, this was often a long process, and there were several small potential pitfalls along the way, such as accidental generation of overlapping serial numbers , or forgetting to reset global fields to default values.

Things are not really better on this front with FileMaker 7. In fact, things are a bit tougher still. Because a file can contain multiple tables, performing an update on a file may mean importing data into a great many tables, even if only a small area of the system has really changed. Separating the tables into several modules, as discussed previously, can help, but the problem remains.

Ideally , we'd be able to take a given data set and just swap a new interface in on top of it without all this talk of mass imports. In FileMaker 7, this is now a reasonable possibility if you separate your data and your interface into two or more separate files.

Let's consider a library book tracking system. It has two main entities, called Item and Patron. An Item is anything the library holds, such as a book, movie, DVD, CD, and so on. There is a many-to-many relationship between Item and Patron, so you also need a join entity, which we'll call Checkout.

This is a thriving public library, and the tables are very large: hundreds of thousands of Items, tens of thousands of Patrons, and literally millions of Checkout records. If you have to reload that data when we make programming changes to the system, you're in for some misery.

Figure 7.32 shows the Relationships Graph for a file called Library. Here you can see the entities, related in the way you'd expect.

Figure 7.32. A Relationships Graph for a system that models a many-to-many relationship between library patrons and library items, via a join file that records each checkout of an individual item.
graphics/07fig32.jpg

There's one slight difference here. As you can tell from the italicized table occurrence names , all these table occurrences are from externally-related files. The three data tables now have a separate physical file of their own.

In theory, you can now do all your interface work in the Library file. You can create all your scripts and user screens in the Library file, leaving the file containing the three data tables alone. If you update a screen or change a script's logic, rather than tinkering with the massive data file, you can just swap in a new Library file (the "viewer" file, if you will) and you'll be all set. And if Library 2.1 has a problem, it's easy enough to roll back to Library 2.0 until you can get 2.1 fixed up.

This is all true and good so far. In all fairness, though, we have to point out that there are some limitations to this technique, as follows :

  • Security ” Accounts and privileges are maintained separately in each file. It's not possible to instruct one FileMaker 7 file to draw its accounts and privileges from another FileMaker file. It's possible to use external authentication methods to offload a lot of the work to an external authentication server, but it's still necessary to create group-to-privilege mapping information in each separate FileMaker file. (For more information on security matters, please see Chapter 12, "Implementing Security.") So in this example, privileges would have to be created and maintained in parallel in both the interface and data files.

  • Multiple Relationships Graphs ” Even in this kind of scenario, the data file is still going to need to be aware of most or all of the structural relationships between data tables. If, for example, you want to create a calculation field that tells you how many items a given patron currently has checked out, that calculation field, which lives in a data table, needs to use a relationship between Patron and Checkout to compute that number. So it isn't possible to build a Relationships Graph in just the "interface" file ”substantial portions of it may need to be replicated in the "data" file as well.

  • "Stickiness" of the data tables ” In theory, changes to scripts or layouts can be accomplished just by swapping out the interface file. But in our experience, many if not most significant updates end up touching the data side as well, even if only to add certain new calculations. The separation methodology described here still doesn't give you a means to avoid making these additions to the data file. However, data file changes are quite a bit easier to write down and replicate than wide- ranging script and layout changes. Manual work may still be necessary in many updates, but it is still much less onerous than doing a massive import of one or more tables.

FileMaker 7 is new enough ”and different enough from its predecessors ”that best practices in these design areas are still emerging. We think, based on early use of the software, that the idea of separation of data and interface is likely to turn out to be a useful one. It won't cure all woes, and it won't always be the right thing to do, but it clearly has the potential to address some vexing problems and open some new doors.

Working Toward Reuse

As a final reason to consider a multi-file structure, consider the idea of reuse. This is in some ways an extension of the earlier discussion of the idea of separating a system into modules. Suppose there's a module that you want to use in several or many different FileMaker systems. You may want to consider isolating the functionality of the module in a single file and including that file in solutions that need the functionality.

As an example, suppose you have a custom-built user management system that keeps track of users, passwords, and privileges. FileMaker 7's new account management features are great, but you still might want to roll your own sometimes.

NOTE

This is especially true in multi-file situations. FileMaker's access privilege system is still slightly hampered because each separate file stores its own account and privilege information, as we discussed above.


You could create a User file that would include a table for user information, as well as tables for user groups ”or even sub-groups, if applicable . If records of user activity, such as logon and logoff times, were required, that information could be stored here as well.

To promote a module's reusability, you could take advantage of a number of new FileMaker features that promote abstraction, such as custom functions and script parameters. Suppose you wanted to create a somewhat generic logging facility (that is, the ability to log user actions to a database table). You could create a Log table with fields for user ID, timestamp, and a textual description of the event. You could then create a logging script that takes a script parameter containing the text to be written to the log, and writes out a log record with this text, the current user ID (presumably stored in a global), and the current timestamp. With planning and forethought, it's possible to create a module in FileMaker 7 with a high degree of reusability.

Let's think about how you might use such a module. First suppose that you're pursuing a strategy of data/interface separation such as the one described earlier in this chapter. Your "main" system consists of two files, MainData (containing all the data tables, but no scripts or interface) and MainViewer (the interface file that contains scripts, layouts, and interface logic). You also have your user module, which is split into two files, UserData and UserAdmin.

You need to create a file reference from MainViewer to UserAdmin. You probably should not need to create a file reference from MainView to UserData. All the main system's interactions with the UserData file should ideally be calls to scripts in UserAdmin; adding log records or checking a user's privileges should not be done by checking the UserData tables directly, but by asking UserAdmin to do this and report on the success or failure of the request.

You would especially want to avoid any logic that would force you to create a table reference from UserAdmin to MainViewer or MainData. UserAdmin shouldn't care about the nature or internals of any files or system that wants to use its services.

Not every group of related tables is likely to be suitable for this kind of " modularization ." But you might want to consider splitting out any subsystems that provide somewhat non-specific functions, such as logging or user management, and making them into their own, semi-connected modules. Careful planning and exploitation of new features such as script parameters can help you create modules that can be smoothly integrated with a variety of different FileMaker systems.

 <  Day Day Up  >  


QUE CORPORATION - Using Filemaker pro X
QUE CORPORATION - Using Filemaker pro X
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 494

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net