How to create a 1 to 1 child table?

[Andrew5]

I am making a substantial addition to my main DB, which currently has two portals and about 40 fields in the parent table. Question: I will adding about 60 fields for some new forms. The fields could just as well be in the parent table but I thinking that it will be awkward to have about 90 fields in the parent table (awkward for me the author and user). Is there a way to create such a joined table that has a 1 to 1 relationship to a parent table, in order for me avoid have 100 fields in my parent table?

Edited October 9, 2008 by Guest

[comment]

It's possible, but hardly advisable. If the parent entity really needs 100 attributes to describe it properly (and this is something I would seriously question), then there should be 100 fields in the parent table. Splitting them off to another table is likely to create more problems than it will solve.

That said, a one-to-one relationship is basically the same as one-to-many: the only difference is that each parent has only one child record.

[Andrew5]

You'd be surprised. Right now I have about 105 layouts in the database and when I add all of the Probate Court forms and form letters I need I'll be up to about 140 layouts. Anyway, thanks for the info.

[comment]

You'd be surprised.

Maybe. But more often than not, inexperienced developers tend to use multiple fields where multiple related records would be more appropriate. If you have any series of fields that are named Field 1, Field 2, Field 3, etc. that's a sign (one of them anyway).

[Vaughan]

You'd be surprised. Right now I have about 105 layouts in the database and when I add all of the Probate Court forms and form letters I need I'll be up to about 140 layouts. Anyway, thanks for the info.

Forms and letters don't have to be individual layouts, especially when there are so many. You should look into a letter templating and merging system: each "letter" is a record in a table that gets the data merged into a couple of different "template" layouts in other tables. I posted a demo file to these Forms years ago when FMP 7 was first released.

An alternative is to use MS Word documents and export merge files with the data.

Using 140 layouts isn't optimal.

[Andrew5]

I'm not sure what you mean by "optimal." It's bad to have over 100 layouts somehow?-- I am new to this but Let me explain:

--I took over a small collections business and put it on FM and learned it from scratch. It works like this: the daily mail gets logged, checks, bills, new law suits, etc. A report is printed each Wednesday which shows, based on the last week's mail, what needs to be done with each case. There are buttons that lead to either scripts or layouts, and either me or the secretary then executes those scripts or go to the layout and paper is produced. Other scripts log that the given work was done. This work used to be the work of a 40 hour secretary but now is done in about 6-8 hours in a week. Like Mozart in "Amedeus" who after hearing the king say his opera had too many notes, "There are exactly as many layouts as there needs to be" as this is a checkbook, and accounting system, form producer, report maker, invoice maker, accounts payable and recievable, calendar, to-do list, letter producer, envelope printer, etc... it's a complete law office in one package, and very little needs to be typed except for the daily mail logs. So it seems to be its incredibly optimal, at least from a user point of view. Perhaps there are limits to Filemaker, but I wouldn't know what they would be. Actually I heard that the entire apple.com site is a big filemaker based DB.