Well - since there is in theory only 1 Addr/job - but, each job can have
multiple Dates/Events as well as multiple Notes & People/job - in theory
your approach seems to make sense. If Notes are related to People - you
could maybe consolidate them. Just my $0.0225 input - adjust up for
inflation...
On 6/15/2018 12:30 PM, [email protected] wrote:
(VFP9SP2 app with MySQL backend)
Some years ago I had created a solution where I had split the main
data table into 5 separate tables, each with a 1:1 relationship. I
kept the commonly held fields in the table, and moved others off like so:
- Main Job table
- Job Address table (job site address)
- Job Dates table (key event dates for this job)
- Job Notes table (all text/memo fields, with key field of course)
- Job People table (folks assigned to the job)
On review, I think this just made more work and I should consolidate
all of these fields inside the single Job table.
Your thoughts on either design approach?
tia,
--Mike
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
