From the course: FileMaker Pro Essential Training

Deciding what fields you will need - FileMaker Pro Tutorial

From the course: FileMaker Pro Essential Training

Start my 1-month free trial

Deciding what fields you will need

“

- [Narrator] Like many other databases, a FileMaker Pro database is presented to a developer as a collection of tables, each containing a number of fields. Now if you've worked with other database environments before you might be accustomed to the term columns instead of fields. Now either term is meaningful and acceptable but the FileMaker Pro user interface and documentation uses the term field and that's what I'm going to call them moving forward here in this course. Couple of quick notes about fields, any single table in FileMaker can have an unlimited amount of fields. It's not a challenge. It's not a constraint either. You should only define fields that are appropriate. So really it's going to be not up to you the developer to kind of come up with what fields you want but you're going to have to talk to your end users or customers if someone's paying you to build the database for them and ask them what information is meaningful. If you remember when we were determining what tables we needed in our database, we were looking for something called entities. Entities then became tables. And an attribute is something that describes an entity. So for example, what we need is something that describes customers. Right now all we have are the default fields that were automatically added when we created this table. So we have to go have some conversations and figure out what fields are necessary in these tables. We already do have some fields inside the product table. That's because we imported this table in from another FileMaker app. But it shows us some examples of attributes that describe a table. So when we start putting data into this table, we'll have a slot where we can put in things like product name or category and cost. Now keep in mind you could have a field that doesn't necessarily have to have a value in it. While in upcoming movies in this chapter we're going to talk about where you can actually put in rules inside your FileMaker database to make sure that users enter data into a certain field. It's not required by default. So you might come up with different fields that don't always have data in them from record to record to record, maybe only certain records have that data. So what we need to do before we can move forward is figure out what the fields are going to be in customers, invoices and products. And in order to do that, we're going to go talk to our end users and ask them what information is meaningful in each one of those groups. So let's say after our discussion we determined we need the following attributes about each customer. Each one of these is going to need to become a field in our customer table. One thing I'd like to point out is that when you're making decisions on attributes that describe entities or the data that's stored inside your tables you want to break the information down to the most granular levels possible. For example, we could have just had one field that was called address where we could have put the street address, city, state and zip. But it's really important that you break down your data into the smallest possible pieces because it's easier to reconstruct them together than it is to parse them out. So that's why we will opt for a street address, city, state or zip because let's say we just want to find out the state or search on a state and not all the other information. The same is true when it comes to names like first name and last name as you see here. Instead of having one full name we decided to break out the first name from the last name. Let's say we're doing a letter and we just want to say dear so and so that way we've got the data isolated in first name. And again we can always concatenate them back together if we need to see them as a full name. Same rules apply here in the invoice fields. We've made some decisions about the attributes that are meaningful to our users and invoices. And it's just a final reminder, not only do you want to break down the fields into the most granular pieces possible but it's also up to your end users to help you decide what information is going to be meaningful. And once you've determined all that you're ready to go define the fields inside the database.

Contents