I am designing a database that is very similar to the situtation described by the following link at PHP Builder.net:

http://www.phpbuilder.com/columns/ba...31.php3?page=5

Basically, we want many URLs. associated with many UserIDs. At the point that 4NF is achieved, the url_relations table holds unique relationships between users and their URLs.

Q: Is this a flawed design, since the database can become overwhelming when holding so many unique relationships between users and their URLs? Imagine if you have 100 users, each associated with 50 different URLID's. It's my understanding that this can lead to 5000 rows.

What is the best way to deal with this kind of situation?

Thanks in advance for your time and help. If my situation hasn't been explained well enough, I'll be happy to elaborate.

Imagine, 5000 rows! ;-)

Don't worry, 5000 rows is chicken feed for a database. 5 million is commonplace, 5 billion is large. (Unless you are using something like Access which is barely a DBMS at all.)

Anyway, what is the alternative? A Users table with 50 columns UrlID1, UrlID2, ...? (No!)

Without knowing a LOT more about your particular usage/system/etc I can't offer a lot of comment on the overall usefulness, correctness, or completeness of your solution.

As Tony pointed out, five million rows will get a database engine to pay attention to your query. Five thousand is "makework" for most engines.

If your schema works for you (and your use of the term 4NF makes me think that it will), the databse engine should happily chew through it with gusto!

-PatP

Edited to correct a minor bone-head on my part. I was talking to one person, and typing about a different person, and confused the names!

However -- in that example they have a RelationID -- this is superfluous and should not be included in your design.

I appreciate all of your help, you hit the nail right on the head...I really didn't have an idea as to the characteristic sizes of a small/medium/large database.

I'll also take MattR's advice, and take out the relationID.

Thanks again for your attention,
Adam

Make sure you set the primary key to be:
(relatedUserId, relatedUrlId)