Jump to content
PGMoneyMan

You're going to love this!

Recommended Posts

PGMoneyMan

If you can solve this, then you get the money prize.

 

I have a need to create a database that has 6 entities (Seller, buyer, title company, contractor, and lender) who will be connected to a particular property. Each of these entities will require 1 or more of 48 "forms".

 

So the layout needs to be the property information on the bottom (which has 6 tabs of info) the buyer and seller contact information at the top (the other four entities information will be on the tabs)

 

I need the ability to 1) search through sellers and buyers and have the ability to press a button to connect that seller or buyer to the current property

 

2) have the ability to press one of 6 or 7 side buttons to create a package of forms with the select information from the property tabs as well as the connected buyer and seller information. A proposed layout is below.

 

Can this work?

 

 

Edited by Ender (IMG tags removed).
http://www.myfundingsource.net:2082/frontend/x/files/showfile.html?dir=%2fhome%2fmpower&file=psplayout.jpg

Share this post


Link to post
Share on other sites
Maarten Witberg

why am I getting a login request for myfundingsource.net each time I refresh this page???? :confused:

Share this post


Link to post
Share on other sites
Ender

Hmm...Junk?

Share this post


Link to post
Share on other sites
PGMoneyMan

Sorry folks, that was my feeble attempt to link to the image of my design lay out. The question still is valid, can this be done.

Share this post


Link to post
Share on other sites
J Wenmeekers
Hmm...Junk?

 

It is clear on the site:

 

"So let us face some realties here:"close this site, it's not for you"".

Share this post


Link to post
Share on other sites
Maarten Witberg

well most of this should be no trouble. you can have a contacts table for instance and use separate foreign keys for each type of entity to a property. 1) is really easy and 2) I'm afraid I don't fully understand what you're after. Should these forms be a part of the database, or blank pages to print out like a questionnaire, or something else entirely.

Share this post


Link to post
Share on other sites
Maarten Witberg

but since Jean Wenmeekers is on this thread I'll say you have to think your database structure through and through and not act on impulse from the first likely reply you're getting :cool:

Share this post


Link to post
Share on other sites
J Wenmeekers

Moved to this spot where it seems to be more appropriate.

Share this post


Link to post
Share on other sites
Jack Rodgers
If you can solve this, then you get the money prize.

 

I have a need to create a database that has 6 entities (Seller, buyer, title company, contractor, and lender) who will be connected to a particular property. Each of these entities will require 1 or more of 48 "forms".

 

So the layout needs to be the property information on the bottom (which has 6 tabs of info) the buyer and seller contact information at the top (the other four entities information will be on the tabs)

 

I need the ability to 1) search through sellers and buyers and have the ability to press a button to connect that seller or buyer to the current property

 

2) have the ability to press one of 6 or 7 side buttons to create a package of forms with the select information from the property tabs as well as the connected buyer and seller information. A proposed layout is below.

 

Can this work?

 

Piece of cake... A few modifications will improve your abilities... Pull the Brink's truck up to my doorstep and .... smiley-wink

Share this post


Link to post
Share on other sites
PGMoneyMan
well most of this should be no trouble. you can have a contacts table for instance and use separate foreign keys for each type of entity to a property. 1) is really easy and 2) I'm afraid I don't fully understand what you're after. Should these forms be a part of the database, or blank pages to print out like a questionnaire, or something else entirely.

 

The forms will be things like Power of Attorney, purchase contracts, repair estimates, etc...The forms will take things like seller and buyer name , address, and calculations

 

you say part one is easy, but when i go to set up, it will only allow me to choose 1 table to display- could you tell me how to display 3 different tables at the same time and be able to search through the individual records in each?

Share this post


Link to post
Share on other sites
Maarten Witberg

From the top of my head (means I didnt make any test files before posting), I can think of two strategies to solve part 1. Both of them start out by recording all contacts or entities as you call them in one and the same contacts table. Makes searching for a person very much easier.

 

Strategy A then consists of creating as many foreign keys in the property table related to the contacts table as there are entities, so 6 as you indicated (means six table occurrences of contacts related to property table). Then store the ID's for each entity in each appropriate foreign key field.

That was what I suggested earlier.

 

Strategy B is use a join table between contacts and properties. In the join table you store contact ID, their entity type and the property ID. You can then view all entities for a project in a portal of the join table- which may be exactly six rows. The creation of the join records may be scripted upon creating a property record so all you got to do then is select contact ID's in each.

Strategy B is probably better.

Share this post


Link to post
Share on other sites
Jack Rodgers

The problem can be simplified if you use a field for Category: customer, re agent, property, etc. and use that for each address. Your address table can then be loaded with details.

 

The Category field can be a checkbox field so you can have numerous categories for each address record.

 

Now you can search for the category and other fields and list all records.

 

Or you can create a multiple link:

 

Category to global category

 

And place the global above the portal so that it will act as a filter for the portal.

 

Add a button or two to the portal rows to perform whatever actions you want.

Share this post


Link to post
Share on other sites
Maarten Witberg
The problem can be simplified if you use a field for Category: customer, re agent, property, etc. and use that for each address. Your address table can then be loaded with details.

The Category field can be a checkbox field so you can have numerous categories for each address record.

 

That option also crossed my mind. But I don't see how this simplifies the problem in the database structure. I would agree if one contact could be only one category, but since a person can be buyer for #1, seller for #2 and a month later, seller for #1 again, it is context dependent and it should be recorded in a join table.

 

The way I read it now a lot of the contracts and so on should also be stored or referred to in this join table.

Share this post


Link to post
Share on other sites
Jack Rodgers

...or you could add the fields:

 

Buyer ID

Seller ID

etc

 

to the applicable table: property, etc.

 

This has value in that if the join file gets corrupted, you're up a creek. But then the join file has its own values. Of course you are just moving these fields from the property record to the join file which now needs the link via record id.

 

Nothing like Gui-Fun-Time!

Share this post


Link to post
Share on other sites
Jack Rodgers
That option also crossed my mind. But I don't see how this simplifies the problem in the database structure. I would agree if one contact could be only one category, but since a person can be buyer for #1, seller for #2 and a month later, seller for #1 again, it is context dependent and it should be recorded in a join table.

 

The way I read it now a lot of the contracts and so on should also be stored or referred to in this join table.

 

One category field can have multiple values (think of a checkbox list). If you link this field to another table, then you have in effect a join table without needing a join table. Making it work is yet to be discussed.

Share this post


Link to post
Share on other sites
Maarten Witberg
a join table without needing a join table

Well, sort of... you are referring to multikey relations. But my picture of the OP's request is that you need to store the contact ID's next to their category / categories. You'd need to concatenate both keys on both ends (contactID & "|"&Category or something). Too convoluted for my taste...I'd stick with a join table in this case.

 

Not to say that multikey relations don't have their uses!

Share this post


Link to post
Share on other sites
PGMoneyMan

I'd like to thank you guys for all your help! I like the idea of the join table.

 

Would any of you be open to me sending you my database file and tell me what you think. I think after you see it, you could get a clear understanding if what I'm trying to do?

Share this post


Link to post
Share on other sites
pgorrell

This is easy stuff to do. What else do you need the site to do?

Share this post


Link to post
Share on other sites
This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

Terms of Use