ISO FileMaker Magazine

Hey Stefano,

Thanks so much for your reply. First, I would like to say that anything I present in any of my videos does not attempt to be an "end all" solution for all situations for all people. No single solution can ever achieve that. To that end...

ANY database structure (or abstraction) being used, must be evaluated based on its use case. If breaking out a phone or email field is required because the field must stand alone (be it for data typing reasons or query performance - for the purpose of searching or statistical reporting) then that's certainly the approach you should take.

Secondly, one thing we're all good at (people in general) is operating from a vantage point that backs up what we already know. When you mention "big drawbacks", I have to evaluate what you define as a "drawback" and what makes it "big". Is it situational and subjective or general and detrimental? I doubt it's the later, as you'll see why.

If the drawback is not being able to simply search an email field directly, as opposed to spending a small amount of effort to create a custom search routine - or use the built-in QuickSearch feature (which provides its own inverse drawback - e.g. benefit), then I'd have to argue that the abstraction isn't as much of a drawback as it is an inconvenience to your current vantage point.

Don't get me wrong, I'm not trying to say you are wrong and I am right. I'm merely saying a coin always has two sides. Yes, having to specify a group id as part of any search on that data may "seem" like extra work, but I'm not doing that. My use case does not dictate extracting an annual household income breakdown based on area code (in which case the phone number would be in multiple individual fields). My use case simply needs to be able to search for contact information - and this is done with the QuickSearch feature.

In short, the data abstraction is not an academic exercise, it is perfectly viable given the needs of the situation.

If there's one thing I can leave you with it's this. It's the mental approach I take to most situations when structuring a database. Data is like water. It will flow wherever you direct it. If I need to break out the phone number field because the requirements change, a quick search and looping script can likely accommodate the new requirements within a few hours (assuming a lot of data - otherwise possibly a few minutes).

Obviously, if you're working with corporate data, with 5M customers, then your approach to the data structure may be quite different than what is shown in the video. ;)

Keep the questions coming, it's great to have the dialog!

Matt

Thanks Josh,

I did look at your file and the solution of continuing to use conditional formatting does work well. There are only a few considerations I would make before going this route.

1. How many times is the same code replicated? If you use complex CustomList() code directly on multiple layout objects then you're not taking advantage of DRY - however, this can be solved with a UI custom function (but some developers don't like adding ui specific custom functions to the file - although I don't know why)

2. Putting a lot of solution logic on layout elements, via conditional formatting works great, it's just not that easy to follow. If some other developer came in and looked at the solution, he/she may be able to decipher this from seeing the conditional formatting (provided they have it turned on in Layout mode), but it's much more clear within a script and trigger.

3. Triggers are there to be used and scripts are more obvious. By putting the code in one script and using a trigger, you accomplish much of what is above. First, you're now DRY compliant - the code is in one place. Second, it's easier to document AND debug and third, it's not as "hidden" as conditional formatting. The line between the UI display and the UI logic is already there for you in terms of the Manage Scripts dialog box being its own unique compartment within the logic of the solution.

Of course, I'll probably still use conditional formatting all over the place, but these were the conclusions I came to when I had to re-evaluate my choice in the first place.

I hope that helps out. :)

Matt