Results 1 to 6 of 6
  1. #1
    Join Date
    Mar 2004
    Posts
    10

    4NF Data Redundancy Problem

    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.

  2. #2
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171

    Re: 4NF Data Redundancy Problem

    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!)

  3. #3
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    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!
    Last edited by Pat Phelan; 03-29-04 at 09:35.

  4. #4
    Join Date
    Mar 2001
    Location
    Lexington, KY
    Posts
    606
    However -- in that example they have a RelationID -- this is superfluous and should not be included in your design.
    Thanks,

    Matt

  5. #5
    Join Date
    Mar 2004
    Posts
    10
    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

  6. #6
    Join Date
    Mar 2001
    Location
    Lexington, KY
    Posts
    606
    Make sure you set the primary key to be:
    (relatedUserId, relatedUrlId)
    Thanks,

    Matt

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •