Re: starting transition fmp 6u to fmp 7: field definition question
- From: Matt WIlls <Im@xxxxxxxx>
- Date: Fri, 10 Aug 2007 17:53:50 GMT
In article <f9i685$bjc$1@xxxxxxxxxxxx>
~consul<consul@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
So I just converted the main database, and will put the other
related files as other tables in the same big file. It does seem to
save space, but that doesn't really matter to me about that.
My question is about field defintions. I have, fer example, [Email]
as a field. There was an email field in the 4 separate ver6 files of
Students, Professors, Community, and Program_Assistants.
Now after combining all 4 files into 1 file with 4 tables, I will
have 4 instances of the [Email] field, which I can see in the
"Database Design" page.
Is that the right way to do it? Or is it efficient database design
to have one field [Email], and 4 different instances of data,
depending on the Table.
I am a little confused because each table can have its own fields
and records, so that makes me think that I have to have separate
[Email] fields, as if the Table were separate files. Is that how I
should think of the Tables when doing relationships and design?
I'm not sure I follow the problem. I know I don't get what you're
describing in the next-to-last paragraph.
If space is not a concern, having an email field in each of four
tables is certainly not something to worry about. You're doing that
for other similar data (e.g., name and phone number, etc.), right?
In terms of efficiency, it makes more sense than yet another table and
setting to set up a relationship to keep track of which address is
whose.
For that matter, you could get by with a single table to contain all
four groups, with a field to identify which group the person is in,
and use separate Table Occurrences to separate them based on
relationship criteria. If you have people who belong to more than one
group, that would be a savings, as the group identifier field could
hold as many values as you have groups. You would need only one record
for each person instead of one for each group he belongs to.
Having the TableName::FieldName construct does help in knowing what's
what, though, so I think I would probably stick with that.
Matt
--
Free FileMaker Technique Demos: http://www.VirtualVermont.com/FMP
My Custom Functions: http://www.briandunning.com/filemaker-custom-functions/results.php?keyword=wills
.
- Follow-Ups:
- References:
- Prev by Date: Re: fmp7 and phone script
- Next by Date: Re: fmp7 and phone script
- Previous by thread: starting transition fmp 6u to fmp 7: field definition question
- Next by thread: Re: starting transition fmp 6u to fmp 7: field definition question
- Index(es):
Relevant Pages
|
