2 Replies Latest reply on Mar 5, 2009 8:40 AM by sheldonrampton

    Object oriented database design



      Object oriented database design


      I've written a blog post about my experience thus far trying to develop object-oriented database design practices for FileMaker:




      The point to this is the same as the point to object-oriented computer programming: To simplify and streamline the development process by enabling reusability of existing designs. For example, a "contacts" database typically requires fields for a person's first and last name, address, city, state, zip code, phone number. Object-oriented design enables creating subclasses of "contacts" such as "media contacts," "donors," "customers," etc. Treating them as subclasses means that they inherit the attributes of their parent class, so I don't have to reinvent the wheel each time and then have separate databases each with their own address and phone number fields.


      There's another aspect to object-oriented design that I'd also like to adopt in my Filemaker databases, but I haven't figured out how yet. I'd like to be able to make my subclasses inherit the methods of the parent class but be able to override them. In object-oriented computer programming, a "method" is the equivalent of a "function" in non-object-oriented programming. In FileMaker, we use scripts. Does anyone have any thoughts on a good way to organize scripts in FileMaker to support inheritance and overriding?


      Here's an example of what I'd like to be able to do: I have a database of investors in the NICA Fund, a project of a nonprofit organization for which I volunteer. Most of our investors lend directly to to the nonprofit organization, but we are currently working to develop a relationship with MicroPlace through which people can find us an invest online. It makes sense for us to define MicroPlace investments as a subclass of our existing investments, and it would be nice if I could have this subclass inherit most of the scripts of the parent database while overriding a few of the scripts that calculate some of the loan terms, such as payment schedules.


      Has anyone else grappled with this type of problem? Any thoughts or suggestions?

        • 1. Re: Object oriented database design

          sheldonrampton wrote:

          Does anyone have any thoughts on a good way to organize scripts in FileMaker to support inheritance and overriding?


          Has anyone else grappled with this type of problem? Any thoughts or suggestions?

          This is what separates the o-o model from the relational model.  The scripts are independent (not encapsulated in the object classes like methods) and therefore can not be easily inherited and are not polymorphic. And parameter driven scripts that try to workaround these problems lead to more complex, fragile, and difficult to maintain solutions. Furthermore, with the exception of the handful of triggers in FMP 10, scripts are procedural in nature rather than event driven like methods.
          At runtime, all 'objects' in FMP are not instantiated so there are no event/message handlers. Probably you will point to third-party plug-ins but these add complexity and cost that are not warranted for the vast majority of form based, user-driven applications that FMP covers well. 


          • 2. Re: Object oriented database design

            Good points. I think the term "object influenced" is better than "object-oriented" to describe what I'm trying to do. I'm not trying to develop a grand scheme or philosophy of how to design in FileMaker. I'm just trying to find a strategy for organizing my own projects and manage complexity, and an object-influenced strategy seems to offer some advantages.


            Based on what you're saying, I think I should probably think of an "class" in my FileMaker design strategy as a combination of database table(s) and a specific layout. For example, I have a table for "investments" and a related table for "MicroPlace" which contains the additional fields needed for processing that particular type of investment. I also have an "Investments" layout, which I can treat as defining the Investments class. Each individual record, as it displays in that layout, would be an object in that class. To create a "Microplace investments" subclass, I duplicate the "Investments" layout and then use Layout setup to make the new layout show data from the "MicroPlace" table. The layout will then have all the fields as the Investments layout, and I just add the additional MicroPlace fields. The "create data from related records" technique that I mentioned in my blog post will ensure that whenever someone creates a new "MicroPlace" table record in the "Microplace investments" layout, they'll also create the necessary related record in the "Investments" table. To end users, therefore, it will simply look like a single record all in one layout -- but one that shares most of the attributes of its "parent class."


            Since most script triggers are tied to layouts, a "MicroPlace investments" layout created in this fashion will also inherit the scripts from its "parent class," and "overriding" a "method" would simply mean something like "change the script which is triggered by the 'calculate investment schedule' button." There's nothing fancy or polymorphically magical about this, but it accomplishes most of what I'm trying to do by way of enabling reuse of design and consistency of behavior among my related objects.


            Once I've done this, of course, subsequent changes to the "Investments" layout will not be automatically reflected in the "Microplace investments" layout, so it's not a true example of object inheritance. However, I think I can live with that limitation.