The content of your record is not limited to user data. Including a field
that provides a unique key is simple: look at the documentation for data
type SERIAL for an easy way to do this.
You can also include information about when the record was inserted, and by
whom, just by including fields in your table definition like:
when_inserted timestamp default now(),
who_inserted text default current_user,
which will be populated automatically every time a record is inserted.
Also, see documentation on triggers for more sophisticated ways of doing
this kind of thing.
> -----Original Message-----
> From: Fons Rave [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, July 21, 2001 7:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Records exactly the same.
>
> > Well, there isn't an easy answer for you ... because you've designed
> > your database wrong. Records should *never* be the same. That is, ni
> > fact, one of the cardinal rules of Relational Database Design.
>
> Well, I started with "I'm a beginner". But I'm sure there's no reason NOT
> to
> accept two records that are exactly the same. In the example I gave, it is
> clear
> that the information I want to store can contain two records that are
> exactly
> the same; doing the same thing, on the same day, for the same amount of
> time. In
> this case it is the technical structure that doesn't want it like that. So
> I
> have to change it to make it work.
>
> Fons.
> [EMAIL PROTECTED]
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
