Welcome Guest, Not a member yet? Register   Sign In
MySQL Design Question
#11

[eluser]insub2[/eluser]
I think I've settled on this:
Code:
Tables
----------------------------------------------
Business [ busID, *busData* ]
Locations [ locID, *locData* ]
BusinessLocations [ branchID, busID, locID ]

Review [ revID, busID, userID, *revData* ]
ReviewLocationss [ revID, branchID ]

Airline [ aLineID, busID, *aLineData* ]
Airport [ aPortID, locID, *aPortData* ]

It's pretty much what I had before with the addition of the BranchID to describe the Business Location Relationship. This should make validating that Business J is actually at Location #27 more direct.

I left the busID in the Review table because, though it's not fully normalized, performing the joins required to get a busID for a Review would be a bit much for something that is used to lookup reveiws so much. Plus, in the unlikely but possible event that a Review's BranchIDs point to multiple businesses, there will be a "master source" for making repairs.
#12

[eluser]jedd[/eluser]
Oh, okay.

I thought branch and location was the same thing.
#13

[eluser]insub2[/eluser]
[quote author="jedd" date="1261199310"]Oh, okay.

I thought branch and location was the same thing.[/quote]

They were at first. Well, there was no "branch". You used the term which got me thinking about using an ID to define the relationship between Business and Locations...yeah.

I'm pretty sure you had a good handle on it this whole time. You've been a big help. Thanks!
#14

[eluser]jedd[/eluser]
[quote author="insub2" date="1261199559"]
I'm pretty sure you had a good handle on it this whole time.
[/quote]

Ha - if only! I just know that talking about, and explaining your schema, often is enough to help you work out different ways of doing things.

The ephemeral, or rather transient nature of things may still bite you later - I'd probably put a bit of thought into coping with that aspect.




Theme © iAndrew 2016 - Forum software by © MyBB