Your first inclination might be to jump onto FileMaker and start building your ideal solution. I know that's what I want to do every time I think of something I want to build. I get excited, I want to start building it, but you really need to make sure you plan your solution. Now, a small solution, maybe to track your CD collection doesn't need that much planning, but you should at least think a little bit about it. Now, a more complex solution that involves multiple tables and, you know, lots of scripts and things, you need a lot of planning with that to make sure it comes out right in the end. Think of it as like building a house. When you're building a house, you start with an architect who gives you plans, and then you hire a contractor. Well think of that as hiring an architect to get plans as the planning stage where you use a number 2 pencil and a piece of paper to draw out all things you want to do and list all the things you want. You know, you list all the fields, all the features, all the tables, you really start making a plan. Think of that as hiring an architect. And then think of building the house, the actual creation of the structure as hiring a contractor to follow those plans, and maybe the architect gets you the contractor, whatever. You know, don't jump right to step 2 of hiring the contractor, don't just jump right on the database and start building it because it's likely that you're going to make a mistake structurally that's going to affect the whole database and you're going to have to pull out or recreate some of the tables, maybe lots of scripts, calculations. I mean, you can get yourself into a lot of trouble, you may even have to start from scratch. So plan your solution, it really is important. Let me tell you a little bit about how commercial developers work. Every developer is different, but in general, commercial developers plan everything by interviewing their clients, listing their features, and creating entity relationship diagrams. They interview their clients over and over and over again and they're very good at asking questions; well, if you want this, do you want it to work this way or that way. Or maybe you want this report, did you think about that? They're really good at getting information and it's really important for you, if you're developing for yourself, to get the information out of yourself. Even if you work for the company, you're an in-house developer, you may still need to watch how people do their job. If you've never done that job before or haven't done it in a while, things may have changed. And by watching somebody do that job, by looking at it and examining everything, you can really get a good idea of how the process flows, and so you really need to do that and really get a good idea about how things work before you can translate what you know into an electronic form of database. You have to first know what you know before you go there, and so make sure you really do know that. We are going to cover Entity Relationship Diagrams, or ERD's in the intermediate tutorials, so you don't really have to know about them, Ôcause they'll only come really essentially when you have multiple tables and we're going to start off in the beginner really not working with only but one table, so don't worry about those for right now. And realize that a commercial developer only starts working on a project once he has signed a Requirements document. That starts the creation process. And before that, it can take as much as 30 to 50% of the project price to develop that Requirements document, so they spend a lot of time on it, and they make the person sign it because, you know, they want that person to make sure, that client, that they have everything in there that they want because if you add something, it may be easy to add, but if they, if the client comes and says, we want this, it may change the whole structure of the database, and could require them to start over, so they're very careful. And you should follow some of these guidelines too, you should be very careful about how you approach creating a database, it's not like a word processor, you don't simply type and then go back up and fill something in. Yeah, sometimes in the database, and especially FileMaker, it's very forgiving, it'll let you do that stuff, but it doesn't always work that way. Make sure you plan out the process and make sure you create a document that tells everything, Ôcause that'll get you to organize your thoughts and really come out with a much better solution, and you'll get to that better solution much more efficiently. OK, so you want to avoid problems, right? That's probably the most important thing, you don't want to get stuck in a dead end street and have to turn around and go a different way. That's not good because it wastes time and you know, for me, I can't stand doing anything more than once, so I want to do it the first time right. Now, I mentioned before smaller projects don't require as much planning because FileMaker's very forgiving, like if you don't add a field in the beginning, well you can go back and add it later, even if you've created a whole bunch of stuff. FileMaker'll let you do that stuff very easily. You can change the name of a field, and it'll update it throughout all the layouts and the scripts and things like that. But still, even with a smaller project, you want to make sure you at least plan it a little bit. You want to think about it in your head, I mean sometimes when I do a database, yeah, I just think about it my head. But when I'm working for a client and I've got a really large project that's going to take me months, you want to make sure that you have it all down on paper and you've thought through the whole thing. In fact, what happens is you often do what's called scrubbing, you go through the structure or solution and think about, OK, can I do this script? Can I get that report? And often what you'll find out is that you'll use that piece of paper and that number 2 pencil to change the structure of your solution over and over again because you'll find out by scrubbing it, by thinking about what you want to do, about the input and the output. You know, the input is how people enter data and the output is how it comes out, printed, report-wise, all that stuff. When you start thinking about that, you'll often find out that, hey, you know what? This is really a many to many relationship, not a one to many, otherwise I can't do this. So you can avoid those problems early on by really sitting down and planning. It's not natural for, you know, most people, especially me, I'm excited, I want to get started, but if you can slow yourself down, especially on the big projects and plan it, you're going to be much better off in the long run.