If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > Breaking 1NF?

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 10-31-07, 08:34
Frunkie Frunkie is offline
Gives Bad Advice
 
Join Date: Mar 2007
Location: 010101010110100
Posts: 791
Breaking 1NF?

Hi everyone,

if I have a table with a field where I wanted to allow multiple values to describe the item in the table, would this be breaking 1NF?

What I want to do is search on this column. In an example, if I entered an item say a year or two ago and I know that I have entered it into the db but I cannot remember the name by which to retrieve the data, I was thinking to use common words by which I would be able to search.

There is no identity amongst all of the columns from which to make a PK. The best identity I can get would be from the names or values I enter into this column. I think that what I am looking for is kind of like "tags" on that delicio.us site. Same principal.


Thanks,

Frank
Reply With Quote
  #2 (permalink)  
Old 10-31-07, 08:53
Pat Phelan Pat Phelan is offline
Resident Curmudgeon
 
Join Date: Feb 2004
Location: In front of the computer
Posts: 12,605
Yes, that definitely breaks 1NF. As such, I'd be agin it (that would be hill-speak, doncha know).

So if your present design looks something like:
Code:
--  ptp  20071031  Bad example, breaks 1NF

CREATE TABLE widgets (
   widgetID		INT
   CONSTRAINT XPKwidgets
      PRIMARY KEY (widgetID)
,  foo			DATETIME
,  bar			VARCHAR(50) DEFAULT 'A place to find Brett'
,  commaSeparatedTags	VARCHAR(255)
   )
I would recommend using something like:
Code:
--  ptp  20071031  Better example, meets 1NF

CREATE TABLE widgets (
   widgetID		INT
   CONSTRAINT XPKwidgets
      PRIMARY KEY (widgetID)
,  foo			DATETIME
,  bar			VARCHAR(50) DEFAULT 'A place to find Brett'
   )

CREATE TABLE widgetTags (
   widgetID		INT
   FOREIGN KEY (widgetID)
      REFERENCES widgets (widgetID)
,  tag			VARCHAR(50)
   )
-PatP
Reply With Quote
  #3 (permalink)  
Old 10-31-07, 09:03
Frunkie Frunkie is offline
Gives Bad Advice
 
Join Date: Mar 2007
Location: 010101010110100
Posts: 791
Thanks for the reply Pat.

I have not yet modeled anything. I have been in a situation many times where I was searching my db, knowing full well that what I need is there but couldn't find it because I don't remember the name I used. I figured I could get past this by using tags.

Thanks for the example Pat..

Frank
Reply With Quote
  #4 (permalink)  
Old 10-31-07, 09:22
Frunkie Frunkie is offline
Gives Bad Advice
 
Join Date: Mar 2007
Location: 010101010110100
Posts: 791
I forgot to ask.. I noticed that you did not use a PK in the widgetTags table. Would you see a problem in using an auto-int for a PK in that table?
Reply With Quote
  #5 (permalink)  
Old 10-31-07, 09:49
Pat Phelan Pat Phelan is offline
Resident Curmudgeon
 
Join Date: Feb 2004
Location: In front of the computer
Posts: 12,605
You certainly could use a surrogate key for the widgetTags table, but do you really need one? This is a case where the table exists solely for the purpose of normalizing the tags... One tag by itself is of little or no value, there is no sequence to the tags, and I'm assuming that all operations on widgetTags would be "all or nothing" (in other words, you wouldn't modify just one tag by itself).

There is nothing wrong with adding the surrogate key, and it could prove helpful in certain conditions, but I can't see a compelling reason to add it from the way that I envision widgetTags being used.

-PatP
Reply With Quote
  #6 (permalink)  
Old 10-31-07, 10:02
Frunkie Frunkie is offline
Gives Bad Advice
 
Join Date: Mar 2007
Location: 010101010110100
Posts: 791
Quote:
Originally Posted by Pat Phelan
You certainly could use a surrogate key for the widgetTags table, but do you really need one? This is a case where the table exists solely for the purpose of normalizing the tags... One tag by itself is of little or no value, there is no sequence to the tags, and I'm assuming that all operations on widgetTags would be "all or nothing" (in other words, you wouldn't modify just one tag by itself).

There is nothing wrong with adding the surrogate key, and it could prove helpful in certain conditions, but I can't see a compelling reason to add it from the way that I envision widgetTags being used.

-PatP
No, I suppose I really don't need one. The only reason I tend to give all of my tables PKs is to conform to a normal form standard but your right.. the table exists only for normalizing the tags and nothing more. Well, I just learned something new.

Thanks again Pat.
Reply With Quote
  #7 (permalink)  
Old 10-31-07, 10:04
r937 r937 is offline
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,524
ALTER TABLE widgetTags
ADD CONSTRAINT widgetTags_PK PRIMARY KEY (widgetID,tag)

stops you from entering the same tag for the same widget more than once
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #8 (permalink)  
Old 10-31-07, 10:30
Frunkie Frunkie is offline
Gives Bad Advice
 
Join Date: Mar 2007
Location: 010101010110100
Posts: 791
I saw that too, after my last post and created a composite PK already. I hate dupes.

Thanks Rudy.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On