New to V.7 - Tables -v- db's

[Serenity]

Hello,

I have used filemaker 6 for some time (being self taught) and have the update to 7. I have only installed it on my PC so far to play with.

I am having difficulty getting out of the mindset of creating new databases for everything I need to relate (i.e v.6)

Could someone please give me the brief low-down on how to better structure my db's or is there a whitepaper somewhere? Basically what i'm looking for is a brief description as to when I use tables -v- a new relational database.

The basic rule of thumb iv'e been playing with is if the information is used by multiple different db's (e.g a list of authors) then i have it in a new database. If the information is used exclusively by that db (e.g contacts - v - companies they work for) then I've created a table. Basically I am looking at creating a new contacts database which incorporates things like the industry they belong to, promotional items sent etc etc so am deciding what i should break up into db's and what i should do as tables.

Any advice would be appreciated. Thank you.

[H.P.]

The main different between fm 7 and 6 is that in fm 6, each table is one separate file. In FM 7, you can combine all those related fm 6 files into one single database. Basically, you take each file in fm 6 into one table. So if in fm 6 you have 10 related files, after moving to FM 7, you will have one single database with 10 tables.

I think it is not necessary to have more than one database in fm 7 for one small or medium size application. One database with multiple related tables/occurances is enough for your solution. Do not break up into multiple databases unless it's a performance or management issue.

[Ender]

Welcome Serenity!

There are a couple theories about the best balance between consolidation and separate files.

1. Convert existing FM6 files and use as-is, with files separate.

2. Consolidate all tables into one file. This makes security setup easy and allows for reuse of scripts through all tables. In a large system, it can make the Table Occurence graph pretty big.

3. Consolidate modules of related tables. This is a good option with a large system where groups of tables are updated all at once. You can upgrade a module offline then move the new module into place without worrying about the rest of the system.

4. Separation of the interface from the data. Data tables can still be in separate files, but there is one Interface file that references all the data tables as necessary. I haven't studied this approach yet, but I understand there is also a Business Logic file in between the Interface and the Data.

These approaches are discussed in the FM7 Migration Foundations and Methodologies white paper. It is heavy reading, but essential for FM7 developers.

[agutleben]

As "Ender" has posted a direct link to the whitepaper on migration above, I would HIGHLY recommend reading the other white papers that are available to you as well. There are so many capabilities and changes with this version that the more knowledge you have the better. I also recommend writing a small DB using FM 7 to start to become aware of the new issues presented if you haven't already.

[Fenton]

There is a lot of controversy about this. My take is that there isn't a right or wrong answer. One factor is whether you're converting v.6 files or starting over. Though, for $200 there is a tool that can pull tables in from files, which overcomes that conversion limitation (PC only at the moment :-|.

The fact that "information is used by several others" isn't all that important, because a Table Occurrence of the file & table in other files will make it available. But there are usually other factors, such as the complexity of the file.

Another large factor is whether you're going to have to update the files often, and how much access you have to them, etc.. If "often" and "little access," then a separation of data and business logic becomes attractive.

However, this means most of your work is in one complex file. The relationship graph would be quite large, requiring a large monitor. The scripts menu would also be quite long. It's true you could organize it into sections, but even so, you're going to lose some time looking.

So, to my mind, ease of development now will have to balanced against ease of updating later. Some day FileMaker may give us more tools, such as folders to group scripts, which would make separation of interface and data solutions easier to develop.

As far as security, it is fairly simple to handle creation and deletion of accounts and their passwords from a central point. I posted one example file of this, and I'm going to post an even easier one (in the Sample files section this time). It needs 3 small scripts which can be imported into every file. You would still need to create Privilege Sets in each file. Complex privileges, with record-level or layout restrictions, have to be created on a table by table level anyway.

It is true that you need fewer scripts with version 7. The Format, Field Behaviour eliminates some pesky "field enterable" scripts. The ability to use Set Field directly from a button eliminates some other small scripts (set date to today, etc.). The fact that Sorts (multiple even) and Import/Exports don't always bug you asking if you want to replace means they don't have to be separate scripts anymore. You don't have to "pass" globals, just use a TO.