Do i need primary key?

Here is the scenario
I have a table (let's call it tblTest) with 3 fields, UserID, Note,
NoteEnterDate (simple one to many relationship. user can have many notes)
Query would be to join it with user table and get the first and last name of
the user (based on UserID) and show the Note and NoteEnterDate (at this
point, I cannot think of any other query that uses this tblTest other than
this).
As far as index is concerned, I think I just need to create clustered index
on UserID.
I know it is good to declare a primary key for every table. Is there a need
for primary key for tblTest perhaps by adding another field called NoteID?
Thanks"Justin" <jus820@.hotmail.com> wrote in message
news:e4OGN5TbGHA.3812@.TK2MSFTNGP04.phx.gbl...
> Here is the scenario
> I have a table (let's call it tblTest) with 3 fields, UserID, Note,
> NoteEnterDate (simple one to many relationship. user can have many notes)
> Query would be to join it with user table and get the first and last name
> of the user (based on UserID) and show the Note and NoteEnterDate (at this
> point, I cannot think of any other query that uses this tblTest other than
> this).
> As far as index is concerned, I think I just need to create clustered
> index on UserID.
> I know it is good to declare a primary key for every table. Is there a
> need for primary key for tblTest perhaps by adding another field called
> NoteID?
>
Would you allow the same (UserID,Note,NoteEnterDate) to be entered twice?
If so, add a synthetic NoteID to tell them apart. If not, create the PK on
(UserID, NoteEnterDate,Note).
David|||you don 't need to waste the space on another column, if the noteid is not
having significance. and if you are going to use an identity for it then its
of no use at all.
u can use user ID and NoteEnterDate as the primary key.
Hope this helps.
--
"Justin" wrote:

> Here is the scenario
> I have a table (let's call it tblTest) with 3 fields, UserID, Note,
> NoteEnterDate (simple one to many relationship. user can have many notes)
> Query would be to join it with user table and get the first and last name
of
> the user (based on UserID) and show the Note and NoteEnterDate (at this
> point, I cannot think of any other query that uses this tblTest other than
> this).
> As far as index is concerned, I think I just need to create clustered inde
x
> on UserID.
> I know it is good to declare a primary key for every table. Is there a ne
ed
> for primary key for tblTest perhaps by adding another field called NoteID?
> Thanks
>
>|||NoteEnterDate is smalldatetime datatype (since we don't basically care about
the seconds). User can type more than one note in a minute. If I create
primary key on UserID and NoteEnterDate, this is not allowed.
Even even if this was not allowed (creating more than one notes in a
minute), what would be the point of creating primary key on UserID,
NoteEnterDate?
Thanks
"Omnibuzz" <Omnibuzz@.discussions.microsoft.com> wrote in message
news:0F05A821-5FFD-4A20-97E2-301565FFA187@.microsoft.com...
> you don 't need to waste the space on another column, if the noteid is not
> having significance. and if you are going to use an identity for it then
> its
> of no use at all.
> u can use user ID and NoteEnterDate as the primary key.
> Hope this helps.
> --
>
>
> "Justin" wrote:
>|||> Even even if this was not allowed (creating more than one notes in a
> minute), what would be the point of creating primary key on UserID,
> NoteEnterDate?
Maybe to prevent someone hitting refresh on your web page, 80 times in a
minute, and populating your table with redundant data.
A|||> you don 't need to waste the space on another column, if the noteid is not
> having significance. and if you are going to use an identity for it then
> its
> of no use at all.
I don't think I particularly agree. What harm does an IDENTITY column do?
I don't think it's as horrible as you make it out to be. The OP doesn't
know all future requirements now, so we can't really gauge its significance,
but let's say you wanted to track notes for some reason (e.g. show who has
viewed them and when). You might create another table called:
CREATE TABLE dbo.NoteTracking
(
? FOREIGN KEY REFERENCES dbo.tblTest(?),
ViewDate SMALLDATETIME
)
Surely you don't suggest it would be better to make up this primary key
UserID,NoteEnterDate and use that as your reference in the secondary table?
Like the OP, I'm not clear on what business sense a primary key on
UserID,NoteEnterDate would make, other than to fulfill the mantra "every
table must have a primary key." If it really is possible (and even
desirable) for a single user to enter two notes in one minute, then we're
back at square one.
A|||All tables must have at least one set of columns that can invariably
identify every row in the table. And there are obvious practical reasons to
explicitly declare one of those sets of columns as the primary key.
Anithsql