Subtitles of the Movie

Your first inclination might be to jump right in to FileMaker and start creating your database. You get really excited about it cause you've got this idea, you think it's going to work and you just jump right on the computer. Well my suggestion is you want to turn that computer off and get out a pencil and paper or you can turn it back on but use a word processor and you need to plan your solution. Sure if you're doing a CD collection that is very simple you really don't need to plan it that much. But once you get to a couple of tables, more complicated solution, you're going to need to plan it to make sure you don't make a mistake. Because mistakes in databases often require you to tear down what you've done. It's like getting into a dead end, you have to turn around and come back and go a different way. Sometimes you can fix things but you really want to make sure that you don't have to do that. You need to make sure that you build your database correctly. It's like building a house; if you're building a house from scratch you don't go out and hire a contractor. First you start with an architect, the architect builds these plans or designs his plans and he shows them to you and you say ÒOh yeah but we wanted a bathroom down there.Ó You know, who knows what you talk about, maybe we want to have this kind of roof and, and instead and he goes ahead and builds these plans for you, then you hire a contractor. It might be his contractor but it could be any contractor. If they're good plans anybody can build them. Don't skip to step 2, getting the contractor; you may have to tear down your house. You don't want to do that, you don't want to start from scratch. And comparing a house to a database is a very good comparison. If you make a mistake on the foundation, which I like to call the relational aspect, the relational structure then you're going to have to tear the whole house down, there's nothing else you can do. So make sure you plan it right, especially in relational structure. A lot of other areas in FileMaker are very forgiving but not the relational structure. Sometimes you get it around them but if your smart and you've got a big project that's going to take you a long time to build, then you want to make sure that you do it right, that you plan it right. So what I want to do is tell you a little bit about what commercial developers do. While you're maybe an in-house developer and very likely you are or maybe somebody uh, just wanting to learn more about databases. You still need to know what the experts do. So experts go out and interview their clients, they talk to them at great length, they ask them questions about things like ÒWell would you maybe want to do this.Ó ÒOh yeah I didn't think about that.Ó It's their job to pull out the information from those clients whether they know it or not that they want it because if they build it and the client goes ÒWell I want a bathroom right in the middle of the house.Ó You're going to have to tear the house down or take some space away; it's not quite that easy. It might be easier with a house where you can maybe go ahead and maybe break down some walls. With a database you really may not be able to do that. So the commercial developer would go out there and list all the features, every single last little detail. We're talking tables and fields and scripts and features and everything and takes it back to the client just like the architect took it back to the person who wanted the house. They're going to take that list of features say ÒIs this exactly what you want? Does this have all the reports you want?Ó And once the client signs off on that then they know they're going to be able to build what they want. They're going to have no problems when they go along and these problems that were created by not getting enough information. They may make a mistake in designing the solution but they certainly won't make a mistake as far as what the client wants and the client won't throw in a feature that they didn't know about. So part of this planning process is entity relationship diagrams or ERD for short. You don't have to know about ERD's right now in the beginner. We'll start covering it in the Intermediate tutorial but I want to mention it right now cause it's a crucial part of building this requirements document that you have the client sign. And even though you maybe an in-house developer you should really still do this stuff with your company. Even if you know the job, even if you've been working there for 10 years, you may not have really gotten down to the details of what this worker does over here cause you need to understand that workflow, how they work in their job. You need to watch them do it, even if it's for a couple hours, ask some questions. You really need to get into that whole workflow and understand how it works so you can design a good solution. So, even if you're an in-house developer you should really get a signed document or at least an e-mail pass back and forth saying these are all the features you want, nothing else? And you may even want to have several meetings saying, ÒOK, have you thought of anything else?Ó And then you come up with ideas. Would you want to do this or that? You know, get the juices flowing so they, your company who's the client will basically uh, start thinking better about what they might want. So, really spend a lot of time on interviewing your client whether it's your boss and other workers or whether you're independent consultant, you really need to do this. Now everybody wants to avoid problems. So let's find out how to avoid them. With a smaller project, it doesn't really require a lot of planning because FileMaker is very forgiving. You can change the name of a field and FileMaker go to every script and every calculation, every layout and change it for you. You can change just about everything in FileMaker except for the structure of your relationship. So, good planning avoids relational structure problems. You don't want to have to figure out that you need this table in the middle way down in the process. You need to consider the structure of the solution, the foundation of your house right away. This will avoid your big problems. And again if you have a small project like a CD collection, not a big deal. But if you got months and months of work, or even a couple of weeks, even a couple of weeks of work you should really plan what you're going to do. And once you've planned it you should go through that structure and scrub it. You should think, ÒOh, I wonder what I have to do here. I wonder if this is gonna support that.Ó And you should say ÒOK, this report, can I do it through there?Ó And you'll visualize it in your head and look at it and see can we make sure that people can input data and output data in the structure. You know output would be reports, inputting would be data entry. Is it all going to be put in together and allows us to do everything we want to do. So you really have to make sure that you scrub that structure. Go to your plan over and over and over again, let it sit for a day, go back to it. Spend a half a day working on it, let it sit for a while, go back to it, really scrub it well, really do all this interviewing and go back and forth, especially in the really complex products. You know as a developer myself who does work for clients I don't do something over again cause if I make a mistake I pay for it; I have to do that over again. So you don't want that to happen to you even if it's just your boss because he's going to lose respect for your abilities and you want to always have the solution come out work the first time you do it.