1 of 1 people found this helpful
What I would suggest immediately is to get an ERD tool that's designed to help you visualize your design (and modify it). I use SQL Editor. It will read your LIVE FMP database and create an ERD. It will also WRITE CHANGES back to your LIVE FMP database.
On first blush, it sounds like you may just need a discriminator column for Charity, but that presumes I understand your DB design.
An ERD (not the RG) is really the first step in understanding, but better yet, communicating your design to others.
2 of 2 people found this helpful
I agree that you likely should have only one People table. The rest of the data model will depend on how much overlap there is between the various organizations in terms of Activities, Attendance, Outcome, and so forth.
Along the same lines as fmpdude's suggestion, to discriminate between the various organizations, I would tend to lean toward the use of join tables between Charity and People, Charity and Activity, Charity and Outcome, etc. That way, you have all your primary entities in one table (per entity), and you connect the charities to the people, activities, outcomes, etc., that are applicable to them.
But you'll have to consider the situation fully, including reporting needs, security, etc., before leaping to a solution.
Thanks Mike, that's useful advice.
SQL Editor sounds very useful. I agree that the Relationship Graph is no substitute for a proper ERD.
Maybe because that’s not the intent?
No, I see that, but I sometimes find myself trying to make do with it (which is my mistake, I know).
Thanks for your reply. Yep, with a good ERD answers to these kinds of questions often almost answer themselves.