Question of Approach 
Author Message
 Question of Approach

I did this project without using DBC's and RI because of the following
issues. I'm curious how anyone else might have approached this and used
DBC's

Essentially:

Buildings (one table) have Management Companies (another table) with a 1-1
relationship between them.

Jobs (a third table) are done on Buildings with a 1-1 relationship between
them.

The difficult part is that Buildings can change management companies. A job
could have been done for building 1 with management company 1 last year and
building 1 with management company 2 this year.

When looking at the jobs for building 1 you have to see management company 1
on last years job and management company 2 on this years job.

I setup a jobs table with pointers to both a building and a management
company for each job and no relationship between buildings and management
companies.

Does any have any problems or comments on this approach?

Thanks,

Jeff



Mon, 29 Aug 2005 04:56:15 GMT  
 Question of Approach
You've just described a classic many-to-many relationship.

One building can have many managers over time. One manager can be related to
many buildings.

The usual solution, which you've called your jobs table, is an intersection
table containing pointers to the parent entities (managers and buildings).

You're spot on.

Although I don't see what any of this has to do with using or not using a
DBC. <g>

Dan


Quote:
> I did this project without using DBC's and RI because of the following
> issues. I'm curious how anyone else might have approached this and used
> DBC's

> Essentially:

> Buildings (one table) have Management Companies (another table) with a 1-1
> relationship between them.

> Jobs (a third table) are done on Buildings with a 1-1 relationship between
> them.

> The difficult part is that Buildings can change management companies. A
job
> could have been done for building 1 with management company 1 last year
and
> building 1 with management company 2 this year.

> When looking at the jobs for building 1 you have to see management company
1
> on last years job and management company 2 on this years job.

> I setup a jobs table with pointers to both a building and a management
> company for each job and no relationship between buildings and management
> companies.

> Does any have any problems or comments on this approach?

> Thanks,

> Jeff



Mon, 29 Aug 2005 05:09:46 GMT  
 Question of Approach
I agree with Dan on the DBC issue.  You can do this with or without using
DBCs, but using DBCs gives you advantages such as the RI code to prevent the
deletion of vital records.

You say 1-to-1 relationships, but then your statements talk about 1 to many
relationships.  For instance, you say "When looking at the jobs for building
1 . . .".  Well the only way a building can have jobs (plural) is to have a
1 (Building table) to Many (Jobs table) relationship.  The Jobs table would
need a foreign key to relate it back to the building table and a foreign key
to relate it back to the the management company.  You could also skip the
management company foreign key and determine who was the management company
at the time of the job based on the date of the job and the dates the
management companies were responsible for the building, but that makes SQL
queries more difficult.

You say you had no relationship between building and management companies.
I'd have one there.  You can kind of figure it out via your jobs table, but
if you just want to quickly list the management companies that have handled
a building over time (and if there was no job during that time - which I
realize may be unlikely depending what these jobs are), then the
relationship between the building and the management company would be
helpful.

Russell Campbell


Quote:
> I did this project without using DBC's and RI because of the following
> issues. I'm curious how anyone else might have approached this and used
> DBC's

> Essentially:

> Buildings (one table) have Management Companies (another table) with a 1-1
> relationship between them.

> Jobs (a third table) are done on Buildings with a 1-1 relationship between
> them.

> The difficult part is that Buildings can change management companies. A
job
> could have been done for building 1 with management company 1 last year
and
> building 1 with management company 2 this year.

> When looking at the jobs for building 1 you have to see management company
1
> on last years job and management company 2 on this years job.

> I setup a jobs table with pointers to both a building and a management
> company for each job and no relationship between buildings and management
> companies.

> Does any have any problems or comments on this approach?

> Thanks,

> Jeff



Mon, 29 Aug 2005 05:57:00 GMT  
 Question of Approach
Thanks,

I'll tell you what the DBC thing is about and any advice is welcome.

I've been doing xbase (mostly fox) since dbase2 and CP/M. Prior to DBC's
coming into existence I took a career detour and worked in C and OS/2 for a
while. When I came back to the Fox world my major client still has some apps
that I haven't been able to port from 2.6 DOS yet. I've got a system that's
75% in VFP but there are major modules in 2.6 DOS which still need to be
re-written. Since I need a database format that can talk to both I've stuck
with 2.6 DOS tables and no DBC.

The bottom line here is that I just haven't learned to use DBC's. That
project that I enquired about earlier in this thread was done in VFP from
scratch without DBC's. The only reason I didn't use DBC's amounts to lack of
familiarity.

Any and all advice welcome and appreciated.

Thanks,

Jeff

Quote:
> You've just described a classic many-to-many relationship.

> One building can have many managers over time. One manager can be related
to
> many buildings.

> The usual solution, which you've called your jobs table, is an
intersection
> table containing pointers to the parent entities (managers and buildings).

> You're spot on.

> Although I don't see what any of this has to do with using or not using a
> DBC. <g>

> Dan



> > I did this project without using DBC's and RI because of the following
> > issues. I'm curious how anyone else might have approached this and used
> > DBC's

> > Essentially:

> > Buildings (one table) have Management Companies (another table) with a
1-1
> > relationship between them.

> > Jobs (a third table) are done on Buildings with a 1-1 relationship
between
> > them.

> > The difficult part is that Buildings can change management companies. A
> job
> > could have been done for building 1 with management company 1 last year
> and
> > building 1 with management company 2 this year.

> > When looking at the jobs for building 1 you have to see management
company
> 1
> > on last years job and management company 2 on this years job.

> > I setup a jobs table with pointers to both a building and a management
> > company for each job and no relationship between buildings and
management
> > companies.

> > Does any have any problems or comments on this approach?

> > Thanks,

> > Jeff



Tue, 30 Aug 2005 06:11:16 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Data Entry Matrix Approach requested.

2. OO approach in FPW _2.6_

3. FoxPro DBF + Lotus Approach

4. Using SQL Server 7 Application Role approach to security

5. Best approach to accounting in VFP?

6. foxpro(xbase)->lotus approach

7. VFP7: Client-Server approach

8. New approach to prevent grid reconstruction

9. VFP7 API Samples : a different approach

10. FP2.x Two Browse screens - one approach

11. Lotus Approach 96 ODBC drivers

12. Help! Looking for best approach for this query...

 

 
Powered by phpBB® Forum Software