> > it easy to change the structure of the FM database, while te data in it
> > doesn't get hurt?
> Howard gave you some good references. But the basic advice is to start
> with pencil and paper.
> Identify each entity in your system. An entity is something you keep
> data about...companies, customers, parts, invoices, etc. Then start
> defining the relationships between those entities to determine where you
> need unique identifiers (study up on creating and maintaining unique
> keys) and where those identifiers will link entities. Draw a chart with
> boxes and lines (this will start you out on file structure and
> relationships between files.)
> Think about what security you'll need in this system. Look into the FM
> manual and the other references for info on FM passwords and groups to
> define access privileges. Next, start thinking about workflow. What
> will the users be DOING with the information? How will they interact
> with it? How much idiot-proofing do you need to do? Do they need to see
> list views, individual record details, what searches will they need to
> perform, what reports do they need to produce?
> The answers to all these questions, which professional developers call
> "needs ysis," will inform your design of the fields you need to keep
> relevant data, the interface you design for users and the order in which
> your construction of the files will proceed.
> In FM, it's pretty easy to change the names of database objects such as
> fields and relationships. It's a bit more complex to change file names
> in mid-stream without the tool that comes with Filemaker Developer.
> Completely changing file structure after starting in one direction is
> possible, but depending on your design choices may be easy or hard.
> Lynn Allen Allen & Allen Semiotics
> FSA Associate Filemaker Consulting & Training
> [email]lynnsemiotics.com[/email] [url]http://www.semiotics.com[/url]