just how flexible IS filemaker?

[nancyc]

i constantly hear the comment filemaker is flexible, it allows you to correct mistakes and reconfigure tables and relationships as your needs evolve...okay, just how flexible IS it? because i also hear be careful, get it right the first time when you're planning out your database structure because if you don't get the relationships right you'll have a mess you can never fully fix. so, where does this leave me, really? CAN relationships be fixed, if you put together an ineffective or inefficient logical flow and disover later you simply cannot operate the searches you need with the structure you have? how much CAN you change once you've set up fields and tables? how hard is it, is it basically reweriting the entire set of scripts that link them together? how can i minimize the complexity of repair and expansion issues when i KNOW i'll have to make modifications down the road?

FileMaker Version: 7

Platform: Mac OS X Jaguar

[RalphL]

Good planning is very important. Get your data grouped into tables, each representing a single object or event. A person, place or thing is an object. An event is occurs at a time and place.

The flexibility of FileMaker is the ability to add new fields, new tables, new layouts & new relationships and to change existing ones. I doubt that you would have to rewrite all of your scripts. Some may require changes and you may need some new ones.

Good documentation will help when the time comes to make changes.

[CyborgSam]

Any relationship mess can be fixed. But it may require extensive mucking of the data (sometimes by hand...). One reason why you want to plan as accurately as possible.

On every project, unforeseen changes occur. The better your understanding of relational databases and data particular to a project, the easier it is to fold in changes.

IMHO, FileMaker is a lot more flexible and easier to change than other DBs.

Blather about my current experience:

I'm doing a set of database for my sister's school. Her previous database system was improperly relational, it duplicated data (like parent's names/addresses) in several locations. She worked around the short comings by typing over printed forms... So when I was analyzing her workflow & dataflow, I got a lot of subjective input based on her bad experience. Once I got her in the groove & had a handle on her work, I had to move data from one db to another so it could become relational. Not that big a task.

By far, the hardest task was getting the data out of run-time Access and mucking it up. The previous programmer held my sister hostage, asking $6000 just to export the data (he didn't just burn his bridges, he nuked them). I spend a couple of days in Access and Excel getting the data out, corrected and importable.