table relationships: defining

BEFOR

Out of the explainations of table relationships I've seen (probably eleven or twelve) each is described with some rather clear cut example. However in real world applications, I think, it is not always so clear cut.

For instance, what about the time factor:

Site users can submit many requests, however usually might only do so over a duration: "I want somebody to paint the exterior of my house this year. I may or may not issue another request about the interior next year, based upon the quality of work received" ie; non-standardized entities.

Also for instance, what about the uniqueness of the entities:

While house painting requests may be made, by many site users, each request is very unique as defined by geographic locale and customization of the project. ie; none are truely the same

Would the above example still be considered a many-to-many?

nemonoman

I think you have missed the point.

Each table represents an information entity.

Your example suggests 2 obvious entities:
User
Request

Your User table would include the standard user info: name, id, etc.

Each User could make 0 to any number of requests. The User-Request relationship is 1 to many (each request has 1 user, each user 0 - N requests)

Your Request table could consist of no more than a User ID and a description column.

You suggest additional request attributes:
type -- (housepainting, plumbing?, cleaning? etc??)
repeating (each year, not each year?)
requeststart/requeststop (1 month?, 1 year?, etc?)
location (zip code?)

Other attributes seem likely, but I don't know your data, example: price range, etc.

Assuming you created a table with these attributes, you could easily find:
all non-repeating housepainting currently available (example
NOW() BETWEEN
requeststart AND requeststop)
in zip code 11111

Each request would be very different (description text would vary).

Each request would be associated with a user. A user might have several requests.

You haven't said so, but another likely entity would be RequestResponse.

In this case a User woujld respond to a request.
RespondingUserId
RequestId
ResponseText

One request, 0-N responses
One responder, 0-N responses

etc.

Hope this helps, or maybe your question is different???

BEFOR

I know this seems very basic, but it's so important. Thanks for the post.While I know your are right, part of this doesn't set and I don't know why.

Request table:

What if two seperate values are are assigned to each request -to make sure the request for house painting is viewed not only by painters but by others (handymen) who do painting as well. I would simply add a second "type2" column to the request table to make certain handymen and painters both would each see the User request -- with number values assigned to each) Then simply add an OR to any relevant query?

You show how a user can respond to a request. (One to many)

What if I would like to show the relationship between all project types (painting, plumbing, whatever) and that of requests -- this a many-to-many? Would this be needed to bridge to the "respond to a request" table?

Roger_Ramjet

Best thing you can do is to read these two articles from this very community

database design
SQL how to

BEFOR

Your example suggests 2 obvious entities: - " nemonoman "

What if each user could only make 1 request making this a 1 to 1 relationship?

Then what about placing the these both, the user and the request on the same table? Would this be a "clustered" table? (need we talk about logical vs. physical storage and joins ?)

nemonoman

You are in a state of confusion, and if the plain information you've gotten here hasn't helped, more posts won't, IMO. Find an actual carbon-based lifeform to speak with, using actual mouth-formed communication. Your questions are very basic, and just about anyone with any relational database experience can set you straight. It's a leap, but once you've leapt, you'll get it. Find a college instructor, local IT guy, etc. who has a clue and ask. Bring a piece of paper, there'll be diagrams to look at.